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Foreword 



rd , 



This Technical Specification has been produced by the 3 Generation Partnership Project (3GPP). 

The contents of the present document are subject to continuing work within the TSG and may change following formal 
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an 
identifying change of release date and an increase in version number as follows: 

Version x.y.z 

where: 

X the first digit: 

1 presented to TSG for information; 

2 presented to TSG for approval; 

3 or greater indicates TSG approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, 
updates, etc. 

z the third digit is incremented when editorial only changes have been incorporated in the document. 
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Scope 



The present document provides the stage 3 specification of the Go interface. The functional requirements and the 
stage 2 specifications of the Go interface are contained in 3GPP TS 23.002 [2] and 3GPP TS 23.207 [3]. The Go 
interface is the interface between the GGSN and the PoHcy Decision Function (PDF). 

The present document defines: 

the protocol to be used between PDF and GGSN over the Go interface; 

the signalling interactions to be performed between PDF and GGSN over the Go interface; 

the information to be exchanged between PDF and GGSN over the Go interface. 
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Definitions and abbreviations 



3.1 Definitions 

For the purposes of the present document, the terms and definitions given in 3GPP TR 21.905 [1] and the following 
apply: 

Application Function: The Application Function (AF) is an element offering applications that require the control of IP 
bearer resources. The AF is capable of communicating with the PDF to transfer dynamic QoS-related application 
information. One example of an AF is the P-CSCF of the IM CN subsystem. 

AF session: An AF session is established by an application level signalling protocol offered by the AF that requires a 
session set-up with explicit session description before the use of the service. One example of an application session is 
an IMS session. 

AF session signalling: AF session signalling is used to control the AF session. One example of AF session signalling is 
SIP/SDP. 

Authorization Token: consists of the AF session identifier and the PDF identifier in conformance with RFC 3520 [11]. 
It is used for authorizing the QoS for the IP flow (s). The UE includes an authorization token as part of the binding 
information in order to obtain QoS authorization for the AF session. The UE obtains this authorization token via the AF 
session signalling from the AF, e.g. via SIP from the P-CSCF by means of an extension SIP header described in RFC 
3313 [22]. The AF communicates with the PDF in order to obtain a suitable authorization token for the UE. 

Binding Information: consists of an authorization token and the flow identifier(s) of IP flow(s) carried by a PDP 
context. When receiving an authorization token, the UE includes binding information when activating or modifying a 
PDP context. It is used for authorizing the QoS of the IP flows carried within a PDP context and to verify that the 
grouping of the IP flows is correct. 

Client Handle: an object in the COPS messages used as a unique number to correlate all the COPS messages with the 
same dialogue. Over the Go interface the Client Handle is used to correlate COPS messages with respect to the same 
PDP Context. For the exact definition see RFC 2748 [7] and RFC 3084 [8]. 

Common Open Policy Service (COPS) protocol: is a simple query and response protocol that can be used to 
exchange policy information between a policy server (Policy Decision Point) and its clients (Policy Enforcement 
Points) 

Flow identifier: used for the identification of the IP flows, described within a media component associated with an AF 
session. A Flow identifier consists of two parts: 1) the ordinal number of the position of the media component 
description in the session description information and 2) the ordinal number of the IP flow(s) within the media 
component description assigned in the order of increasing port numbers. Examples are provided in Annex C. 

Go Interface: interface between PDF and GGSN (3GPP TS 23.002 [2]) 

Gq Interface: interface between PDF and the AF. It is specified in 3GPP TS 29.209 [23] 

GPRS Charging ID (GCID): the Charging Id generated by the GGSN as defined in 3GPP TS 29.060 [20]. 
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IP Bearer Service Manager: uses standard IP mechanisms to manage the IP Bearer Service. It resides in the GGSN 
and optionally in the UE. 

IP flow: a unidirectional flow of IP packets with the same source IP address and port number and the same destination 
IP address and port number and the same transport protocol. Port numbers are only applicable if used by the transport 
protocol. 

Media component: is a part of an AF session description (e.g. SDP) conveying information about media (e.g. media 
type, format, IP address, port(s), transport protocol, bandwidth, direction). 

The media described by a media component can be either bi- or unidirectional. Media using RTP for transport may also 
have associated RTCP If so, the media component also conveys information about the associated RTCP (port and 
possibly bandwidth). An AF session description can consist of more than one media component. 

For, SDP, a media component shall not be deleted nor its position changed within the SDP session description. An SDP 
media component line where the port number has previously been set to may be reused for a new media component. 

Policy Decision Function (PDF): is a logical policy decision element that uses standard IP mechanisms to implement 
policy in the IP media layer 

The PDF makes decisions in regard to network based IP policy using policy rules, and communicates these decisions to 
the PEP in the GGSN. 

Proxy Call Session Control Function (P-CSCF): is a network element providing session management services 
(e.g. telephony call control) 

Policy Enforcement Point (PEP): is a logical entity that enforces policy decisions made by the PDF. It resides in the 
IP BS Manager of the GGSN 

Policy Information Base (PIB): is a set of policy data carried by COPS-PR 

The protocol assumes a named data structure, known as a Policy Information Base (PIB), to identify the type and 

purpose of solicited and unsolicited policy information that is sent from the Policy Decision Point to the Policy 

Enforcement Point for provisioning policy or sent from the Policy Enforcement Point to the Policy Decision Point as a 

notification. 

Provisioning Instance Identifier (PRID): uniquely identifies an instance of a PRC 

QoS class: identifies a bearer service (which is associated with a set of bearer service characteristics) 

Session Description Information (SDI): The set of information describing the AF session (e.g. type of media, 
bandwidth, IP address and port number) agreed between the UE and the AF required to perform the Service Based 
Local Policy (SBLP).. For example, in the IMS case, this information is negotiated between the UE and AF using SDP. 

Service Information: The set of information conveyed from the AF to the PDF over the Gq interface to be used as a 
basis for the service-based local policy decisions at the PDF, including information about the AF session (e.g. 
application identifier, type of media, bandwidth, IP address and port number) and parameters controlling the PDF 
behavior. The encoding of the service information is provided in 3GPP TS 29.209 [23]. 

Translation/mapping function: provides the inter-working between the mechanisms and parameters used within the 
UMTS Bearer Service and those used within the IP Bearer Service 

UMTS Bearer Service Manager: handles resource reservation requests from the UE. It resides in the GGSN and the 
UE 

3.2 Abbreviations 

For the purposes of the present document, the abbreviations given in 3GPP TR 21.905 [1] and the following apply: 

AF Application Function 

COPS Common Open Policy Service protocol 

COPS-PR COPS for policy PRovisioning 

DEC COPS DECision message 

DRQ COPS Delete ReQuest state message 

GCID GPRS Charging IDentifier 

ICID IM CN Subsystem Charging IDentifier 
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IMS IP Multimedia core network Subsystem 

MIB Management Information Base 

P-CSCF Proxy Call Session Control Function 

PDF Policy Decision Function 

PEP Policy Enforcement Point 

PIB Policy Information Base 

PRC PRovisioning Class (a type of policy data) 

PRI PRovisioning Instance (an instance of a PRC) 

PRID PRovisioning Instance iDentifier 

QoS Quality of Service 

REQ COPS REQuest message 

RPT COPS RePorT state message 

RTCP RTP Control Protocol 

SBLP Service Based Local Policy 

SDI Session Description Information 

SDP Session Description Protocol 



Go interface 



4.1 



Overview 



The Go interface allows service-based local policy information to be "pushed" to or requested by the Policy 
Enforcement Point (PEP) in the GGSN from a Policy Decision Function (PDF). As defined in the stage 2 specifications 
3GPP TS 23.207 [3], this information is used by the GGSN for: 

GPRS bearer authorisation; 

- Charging correlation; 

Policy based "gating" function in GGSN; 

The Go interface uses IP flow based policies. 

The Common Open Policy Service (COPS) protocol has been developed as a protocol for use between a policy server 
and a network device, as described in RFC 2748 [7]. 

In addition, COPS for Provisioning extensions have been developed as described in RFC 3084 [8] with RFC 3159 [9] 
describing a structure for specifying policy information that can then be transmitted to a network device for the purpose 
of configuring policy at that device. The model underlying this structure is one of well-defined provisioning classes and 
instances of these classes residing in a virtual information store called the Policy Information Base (PIB). 

The Go interface shall conform to the IETF COPS (RFC 2748 [7]) and the extensions of COPS-PR (RFC 3084 [8]). For 
the purpose of exchanging the required specific Go information, a 3GPP Go COPS-PR Policy Information Base (PIB) is 
defined in the present document. 

COPS Usage for Policy Provisioning (COPS-PR) is independent of the type of policy being provisioned (QoS, Security, 
etc.). In the present document, COPS-PR is used to communicate service-based local policy information between PDF 
and GGSN. COPS-PR can be extended to provide per-flow policy control along with a 3GPP Go Policy Information 
Base (PIB). The 3GPP Go PIB may inherit part of the data object definitions from other PIBs and MIBs defined in the 
IETF. 

Signalling flows related to the Go interface are specified in 3GPP TS 29.208 [18]. 

The minimum functionalities that the Go interface shall cover are introduced below. 

1 . Media Authorisation request from GGSN: 

The GGSN receives the binding information during the activation of a (Secondary) PDP context or during the 
modification of an existing PDP context that has been previously authorized by the PDF. To authorise the 
PDP context activation, the GGSN shall send a media authorisation request to the PDF. To authorise the PDP 
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context modification, the GGSN shall send a media authorisation request to the PDF when the requested QoS 
exceeds the authorised QoS or new binding information is received. 

This authorisation request shall include the following information: 

Binding information: 

The binding information is used by the GGSN to identify the correct PDF and subsequently request 
service-based local policy information from the PDF. The GGSN may receive one or more sets of the 
binding information during an activation or modification of a PDP context. Each set of binding 
information consists of: 

One Authorisation token; 

One or more Flow identifiers within the session. 

2. Media authorisation decision from PDF: 

The media authorisation information sent by the PDF to the GGSN, contains at a minimum the following 
information: 

Decision on the binding information. 

The PDF shall respond with an authorisation decision for the binding information. The authorisation decision 
shall identify that the binding information is validated with an ongoing AF session. Additionally, the PDF shall 
verify if the IP flows of the multiple media components are correctly assigned to the PDP Context. If validated, 
the PDF shall also communicate the following media authorisation details to the GGSN: 

- "Authorised QoS". 

This information is used by the GGSN to authorise the media resources according to the service-based 
local policy and the requested bearer QoS. 

The "Authorised QoS" signalled over the Go interface is based on the service information requirements 
conveyed over the Gq interface, which are based on SDI possibly signalled and agreed previously within 
AF session signalling for this session. 

The "Authorised QoS" specifies the maximum QoS that is authorised for a PDP context for that specific 
binding information. In case of an aggregation of multiple media components within one PDP context, the 
combination of the "Authorised QoS" information of the individual IP flows of the media components is 
provided as the "Authorised QoS" for the bearer. 

The "Authorised QoS" contains the following information: 

QoS class: 

The QoS class information represents the highest class that can be used for the media component. It is 
derived from the service information received from the AF. The QoS class within the "Authorized 
QoS" information for the bearer is determined from the QoS class values of the individual IP flows of 
these media components identified in the binding information. 

Data rate: 

The Data rate information is derived from the service information. In the IMS case, it is derived from 
the SDP bandwidth parameters converted by the P-.CSCF to bandwidth information within the service 
information. The Data rate includes all the overhead coming from the IP-layer and the layers above, 
e.g. UDP, RTP or RTCP. If multiple codecs are agreed to be used in a session, the authorized data rate 
is set according to the codec requiring the highest bandwidth, meaning that terminals may under use 
the authorized data rate when choosing to use another agreed codec. The Data rate within the 
"Authorized QoS" information for the bearer is determined from the data rate values of the individual 
IP flows identified in the binding information. 

Packet Classifier. 
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The packet classifier for media components is based on the IP-address and port number information in the 
service information and shall allow for all IP flows associated with the service information media 
component description. 

3. Charging correlation: 

The PDF may send the AF charging information e.g. ICID (see 3GPP TS 24.229 [14]) provided by the P-CSCF 
in the IMS case, as part of the authorisation decision. The GGSN shall send the GCID (see 3GPP TS 29.060 
[20]) of the PDP Context and the GGSN address to the PDF as part of the authorisation report. 

4. Approval of QoS Commit / Removal of QoS Commit / Revoke Authorisation for GPRS and IP resources: 

The PDF controls media components and may revoke resources at any time. Approval of QoS Commit / 
Removal of QoS Commit / Revoke Authorisation for GPRS and IP resources is communicated by the PDF to the 
GGSN. 

5. Indication of PDP Context Release / Modification to/from kbit/s: 

The GGSN informs the PDF of bearer changes related to the authorised resources for the AF session in the 
following cases: 

Loss of radio contact (modification to/from kbit/s for conversational and streaming class); 

Deactivation of PDP context. 



4.2 



Go reference model 



The Go interface is defined between the PDF and the GGSN (3GPP TS 23.002 [2]). 

The PDF is in the same PLMN as the GGSN. 

The relationships between the different functional entities involved are depicted in figure 4.2. 
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AF Session Signalling 
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NOTE: For clarity in the diagram, network elements that are not involved in service-based local policy are not 
presented here (e.g. radio network elements, SGSN, etc). 

Figure 4.2: Go interface architecture model 
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4.3 Functional elements and capabilities 

4.3.1 GGSN 

4.3.1 .1 Service-based local policy enforcement point 

The Policy Enforcement Point (PEP) is a logical entity which resides in the GGSN and communicates with the PDF 
regarding Service-based local policy (SBLP) control. Hereafter in the present document, the GGSN is assumed to 
contain the PEP implicitly unless otherwise stated. The GGSN sends requests to and receives decisions from the PDF. 
The GGSN may cache the policy decision data of the PDF decisions. This cached information may be used later for a 
local policy decision allowing the GGSN to make policy control decision about the QoS authorization for PDP context 
modifications without requiring additional interaction with the PDF in case the modification request does not exceed the 
previously authorized QoS. 

The following policy enforcement point functionalities for SBLP in the GGSN are identified: 

Policy based Authorisation: 

The GGSN requests authorisation information from the PDF for the IP flows carried by a PDP context. The 
GGSN enforces the PDF decisions for this PDP context. 

The GGSN shall enforce unsolicited authorisation decisions which update the QoS and packet classifiers. 

Additionally, policy-based authorisation ensures that the resources, which can be used by the PDP context 
are within the "Authorised QoS" specified by the PDF. This information is mapped by the 
Translation/mapping function in the GGSN to give the authorised resources for GPRS bearer admission 
control. 

The GGSN shall also report to the PDF its success or failure in carrying out the PDF decision. 

Policy based gating functionality: 

Policy based gating functionality represent the control of the GGSN over the Gate Function in the user plane, 
i.e. the forwarding of IP packets associated with a media component. In the user plane, a "gate" is defined for 
each IP flow of a media component. The PDF provides the gate description and the commands to open or 
close the gate. The gate description is received from the PDF in the authorisation decision. The command to 
open or close the gate shall be sent either in the authorisation decision or in subsequent decisions from the 
PDF. 

Indication of bearer release/modification to/from kb/s: 

The GGSN shall inform the PDF when the bearer changes to or from a data rate of kb/s (an indication of 
bearer loss/recovery), and at bearer release. 

- Charging Correlation 

To ensure charging correlation, the PEP shall send the GCID and the GGSN address to the PDF. The PDF 
shall also send the AF charging identifier, if available, to the GGSN. 

4.3.1 .1 .1 QoS Information processing 

The GGSN is responsible for the policy based authorisation, i.e. to ensure that the requested QoS is in-line with the 
"Authorized QoS". 

The GGSN needs the "Authorised QoS" information of the PDP context for the uplink as well as for the downlink 
direction. Therefore, the "Authorized QoS" information for the combination of all IP flows of each direction associated 
with the media component as determined by the PDF is used. 

In case of an aggregation of multiple media components within one PDP context, the "Authorised QoS" for the bearer is 
provided by the PDF as the combination of the "Authorised QoS" information of the individual media components. 
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The GGSN shall perform the proper mapping between the IP QoS information and the UMTS QoS information. This 
mapping is performed by the Translation/mapping function which maps the "Authorised QoS" information for the PDP 
context into authorised UMTS QoS information. 

The GGSN shall derive the highest allowed UMTS Traffic class for the PDP context from the QoS class in the 
"Authorized QoS" according to table 4.3.1.1.1. 

Table 4.3.1.1.1 



QoS class 


UMTS Traffic Class 


Traffic Handling Priority 


A 


Conversational 


N/A 


B 


Streaming 


N/A 


C 


Interactive 


1 


D 


2 


E 


3 


F 


Background 


N/A 


NOTE: QoS class represents the highest class that can be used for the bearer. 



The QoS class values given by the PDF are equal for both the uplink and the downlink directions. 

The Data rate within the "Authorized QoS" information for the bearer is the combination of the data rate values of the 
"Authorised QoS" of the individual IP flows of the media components. 

In the case of real-time UMTS bearers (conversational and streaming traffic classes), the GGSN shall consider, the Data 
rate value of the "Authorized QoS" information as the maximum value of the 'Guaranteed bitrate' UMTS QoS 
parameter, whereas the 'Maximum bitrate' UMTS QoS parameter is limited by the subscriber and service specific 
setting in the HLR/HSS (SGSN) and by the capacity/capabilities/service configuration of the network (GGSN, SGSN). 
In the case of non-real-time bearers (interactive and background traffic classes) the GGSN shall consider, the Data rate 
value of the "Authorized QoS" information as the maximum value of the 'Maximum bitrate' UMTS QoS parameter. 

The UMTS BS Manager receives the authorised UMTS QoS information for the PDP context from the 
Translation/mapping function. If the requested QoS exceeds the authorised QoS, the UMTS BS Manager shall 
downgrade the requested UMTS QoS information to the authorised UMTS QoS information. 

The GGSN may store the authorized QoS for the binding information of an active PDP context in order to be able to 
make local decisions, when the UE requests for a PDP context modification. 



4.3.1.2 



Initialisation and maintenance 



The GGSN shall comply to the procedures described in RFC 2748 [7] for the initialisation and maintenance of the 
COPS protocol over the Go interface. 



4.3.1.3 



Gate function 



The Gate Function represents a user plane function enabling or disabling the forwarding of IP packets. A gate is 
described by a set of packet classifiers that identify IP flows associated to the gate. The packet classifier includes the 
standard 5-tuple (source IP address, destination IP address, source port, destination port, protocol) explicitly describing 
a unidirectional IP flow. 

The packet classifier is received from the PDF in an authorisation decision. 

The GGSN installs the packet filter corresponding to the packet classifier. The packet classifier includes the status that 
the gate shall be set to. 

The commands to open or close the gate lead to the enabling or disabling of the passage for IP packets. If the gate is 
closed all packets of the related IP flows are dropped. If the gate is opened the packets of the related IP flows are 
allowed to be forwarded. The opening of the gate may be part of the authorisation decision event. The closing of the 
gate may be part of the revoke authorisation decision event. 

IP Packets matching a SBLP supplied filter are subject to the gate associated with that packet filter. In the uplink 
direction, IP packets which do not match any SBLP supplied filter shall be silently discarded. In the downlink direction, 
IP packets which do not match any SBLP supplied filter shall be matched against TFT supplied filters that are installed 
for PDP contexts where SBLP is not applied. 
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4.3.1.4 Void 

4.3.1.5 Binding mechanism handling 

The binding information is used by the GGSN to identify the correct PDF and subsequently request service-based local 
policy information from the PDF. The binding information associates a PDP context with one or more media 
components or IP flows of an AF session. The GGSN may receive one or more sets of the binding information during 
an activation or modification of a secondary PDP context. Each set of binding information consists of an authorisation 
token and the flow identifier(s) related to the IP flow(s) within the same session 

The GGSN shall store the binding information and apply it to correlate events and actions between the PDP context and 
the service-based local policy. 

The GGSN shall determine the IP address of the PDF from the PDF identifier received as part of the Authorization 
Token. This identifier shall be in the format of a fully qualified domain name. If the GGSN receives multiple sets of 
binding information in the secondary PDP context activation, the GGSN shall search for the first Authorization Token 
containing the PDF identifier (Authorization Token is of type AUTH_SESSION and contains AUTH_END _ID) and 
use that to identify the correct PDF. If none of the tokens included in the binding information are of type 
AUTH_SESSION, or they do not contain an AUTH_ENT_ID attribute to resolve the PDF address, then the GGSN shall 
reject the secondary PDP context activation request. The reason for the rejection is indicated to the UE with the error 
code value "Invalid binding information" (see annex D). 

The GGSN shall forward the binding information received from the UE to the PDF. If multiple sets of binding 
information are received by the GGSN, it shall forward them to the PDF. 

If the binding information is successfully modified using the PDP context modification procedure, the GGSN shall 
replace the old binding information with the new binding information. 

When the GGSN receives a secondary PDP context activation request to an APN for which the Go interface is enabled 
and no binding information is received, the GGSN may either reject the secondary PDP context activation request, or 
accept it within the limit imposed by a locally stored QoS policy. This local QoS policy shall be operator configurable 
within the GGSN. If the request is rejected, the reason for the rejection is indicated to the UE with the error code value 
"Missing binding information" (see annex D). If the requested PDP context is non-realtime (UMTS Traffic class 
'background' or 'interactive') and such a PDP context is not yet assigned for the UE for the same APN, then the GGSN 
shall accept the secondary PDP context activation request without binding information and SBLP authorization. If such 
a PDP context is already assigned, then the GGSN may accept the secondary PDP context request according to operator 
policy. 

When the GGSN receives a PDP context modification request for a secondary PDP context to an APN for which the Go 
interface is enabled, and no binding information is received (e.g. due to a SGSN initiated PDP context modification of 
maximum bitrate to kbit/s), the GGSN shall accept the PDP context modification if binding information has been 
previously provided for the PDP context. SBLP still applies for this PDP context. If a request for service-based local 
policy information from the PDF is necessary, the GGSN shall use the stored binding information of this PDP context. 

If no binding information has previously been received, the GGSN may either reject the PDP context modification 
request, or accept it within the limit imposed by a locally stored QoS policy. This local QoS policy shall be operator 
configurable within the GGSN. If the request is rejected, the reason for the rejection is indicated to the UE with the 
error code value "Missing binding information" (see annex D). If the modified PDP context is non-realtime (UMTS 
Traffic class 'background' or 'interactive'), then the GGSN shall accept the secondary PDP context modification request 
without binding information and SBLP authorization. 

When binding information is received, the GGSN shall ignore any UE supplied TFT, and filters in that TFT shall not be 
installed in the packet processing table. 

The GGSN shall reject a secondary PDP context activation or PDP context modification request with the error code 
"Binding information not allowed" (see annex D) in the following cases: 

The Go interface is disabled and the GGSN receives a Create PDP Context Request or Update PDP Context 
Request message that includes binding information. 

The GGSN receives a Create PDP Context Request or Update PDP Context Request message that includes both 
binding information and the IM CN Subsystem Signalling Flag. 
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The GGSN receives an Update PDP Context Request message that includes binding information to modify a 
previously non-authorized PDP context. 

4.3.2 PDF 

4.3.2.1 Service-based local policy decision point 

The PDF functions as a Policy Decision Point for the service-based local policy control. The PDF makes policy 
decisions based on session and media related information obtained from the AF via the Gq interface. The PDF shall 
exchange the decision information with the GGSN via the Go interface. 

The following policy decision point functionalities for SBLP are identified: 

Authorisation function: 

The PDF shall be able to provide an authorisation decision upon receiving a bearer authorisation request from 
the GGSN. The PDF shall authorise the request according to the stored session and media related information 
received from the AF. 

The PDF shall use the binding information to determine the AF session(s) and the set of IP flows. Multiple 
sets of binding information and multiple AF sessions may be involved, if flows from separate AF sessions are 
multiplexed in the same PDP context. Based on the IP flows, the PDF shall determine the authorised QoS, 
packet filters, and gate status to be applied. The authorised QoS specifies the maximum allowed QoS class, 
and the data rate for the set of IP flows identified in the binding information. 

The PDF shall be able to provide updates to the authorisation decision, if receiving modified service 
information from the AF which changes the QoS and packet classifiers for PDP contexts which are already 
established. 

Revoke function: 

The PDF may revoke the authorisation of resources at any time. Revoke Authorisation for GPRS and IP 
resources is communicated by the PDF to the GGSN. 

Approval of QoS Commit / Removal of QoS Commit: 

The PDF may allow or deny the usage of the PDP context for the selected IP flow(s) by controlling the 
correlated gate(s). 

The "Approval of QoS Commit" command may either be part of the authorisation decision, or the PDF may 
provide a separate decision with the "Approval of QoS Commit" command to open the gate. 

The "Removal of QoS Commit" command is a separate decision to close the gate(s) e.g. when a media IP 
flow(s) is put on hold. 

Actions due to Indication of bearer release: 

When the GGSN informs the PDF of bearer deactivation, the PDF shall remove the corresponding 
authorisation request state. Additionally, the PDF shall inform the AF about this deletion event. 

Actions due to Indication of bearer modification: 

When the PDF receives an indication of bearer modification of the maximum bitrate to or from kbits/s, the 
PDF shall inform the AF about this modification event. 

Generation of authorisation token: 

The PDF generates an authorisation token for the AF session as specified in 3GPP TS 29.209 [23]. 

Mapping service information to "Authorized QoS" parameters: 

To perform proper authorisation, the PDF shall map the necessary service information containing session and 
media related information to "Authorized QoS" parameters. 

- Charging identifiers exchange: 
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The PDF shall send the AF charging information (e.g. ICID if the AF is P-CSCF) , if provided by the AF, as 
part of the initial authorisation decision(s) for all the bearer authorization request(s) that correspond to the 
respective AF session. 

When the PDF receives the GCID together with the GGSN address from the GGSN, it shall forward this 
information to the AF to ensure charging correlation. This information should not be forwarded over an inter-operator 
interface. 

4.3.2.2 Initialisation and maintenance 

The PDF shall comply to the procedures described in RFC 2748 [7] for the initialisation and maintenance of the COPS 
protocol over the Go interface. 

4.3.2.3 Binding mechanism handling 

The binding information is used by the GGSN to identify the correct PDF and subsequently request service-based local 
policy information from the PDF. Each set of binding information consists of an authorisation token and one or more 
flow identifier(s). 

The PDF generates an Authorisation Token for the AF session as specified in 3GPP TS 29.209 [23]. The Authorisation 
token shall be sent to the AF which forwards it to the UE in the AF session signalling. The PDF shall provide its PDF 
identifier as part of the Authorization Token. This identifier shall be in the format of a fully qualified domain name. 

The PDF receives the binding information and a Client Handle as part of a REQ from the GGSN. The PDF shall store 
the Client Handle for each flow identifier identified by the binding information for subsequent message exchanges. 

The authorisation token is applied by the PDF to identify the AF session. If flows from separate AF sessions are 
multiplexed in the same PDP context, there are more than one authorization token, and the PDF identifies one AF 
session per each token. If no AF session can be found for an authorisation token, or if the authorization token for the 
Client Handle has been modified, or if the PDF is otherwise unable to authorise the binding information, the PDF shall 
send a COPS decision message carrying both an INSTALL and REMOVE decision. The INSTALL decision shall 
identify an authorisation failure to the GGSN, and may include further details identifying the cause. The REMOVE 
decision shall subsequently remove this state from the GGSN. The "Request State" flag shall not be set within the 
REMOVE decision. For an initial authorisation, the GGSN will send a COPS Delete Request State (DRQ) message to 
the PDF to clean up the corresponding COPS handle. 

For a valid authorisation token the flow identifier(s) are used to select the available information on the IP flows of this 
AF session. The PDF sends the available authorisation information back to the GGSN. If there are more than one 
authorization tokens per client handle, the authorization information comprises an aggregate of the information of all 
related flows. If the PDF has already communicated authorisation for the same authorisation token and flow identifier(s) 
to this (or another) GGSN on this AF session, then the previous authorisation shall be revoked, and this revocation shall 
be communicated to the appropriate GGSN. 

If the binding information consists of more than one flow identifier, the PDF shall also verify that the media 
components identified by the flow identifiers are allowed to be transferred in the same PDP context. If any of these 
media components was mandated to be carried in a separate PDP Context, the PDF shall send a COPS decision message 
carrying both an INSTALL and REMOVE decision. The INSTALL decision shall identify an authorisation failure to 
the GGSN, and may include further details identifying the cause. The REMOVE decision shall subsequently remove 
this state from the GGSN. For an initial authorisation, the PDF shall then initiate a remove for the authorisation request. 

For a valid binding information consisting of more than one flow identifier, the information sent back to the GGSN 
shall include the aggregated QoS for all the IP flows and suitable packet filter(s) for these IP flows. If there are more 
than one sets of binding information per client handle, the authorization information comprises an aggregate of the 
information of all related flows. Each flow identifier within the binding information can identify one or more IP flows 
of a single media component. 
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5 Policy control procedures 

5.1 GGSN 

5.1 .1 Initial authorization at PDP context activation 

The GGSN may receive binding information during the activation of a secondary PDP context by the UE. To perform 
initial authorization at the secondary PDP context activation the GGSN shall send an authorisation request to the PDF 
including the binding information received from the UE. 

The GGSN identifies the required PDF from the authorisation token of the binding information. The authorisation token 
is formatted according to the structure of the policy element AUTH_SESSION defined in RFC 3520 [11]. The policy 
element AUTH_SESSION shall include the AUTH_ENT_ID and the SESSION_ID attributes. The GGSN checks for 
that Policy Element and retrieves the AUTH_ENT_ID attribute from this. If this is in the form of a Fully Qualified 
Domain Name, then this is used to identify the correct PDF. 

The GGSN authorisation request message to the PDF shall allow the GGSN to request policy information for 
authorisation of the IP flows identified by the flow identifiers within the binding information carried by a PDP context. 

When the GGSN receives the PDF decision, the GGSN shall enforce the policy decision. To enforce the policy 
decision, the GGSN shall install the packet filters received from the PDF, and ignore the UE supplied TFT. 

If the PDF decision information indicates that the binding information provided by the GGSN is authorised, the GGSN 
shall proceed with activation of the secondary PDP context. The GGSN shall map the authorized QoS resources into 
authorized resources for the bearer admission control. 

To ensure charging correlation, the GGSN shall send the GCID and GGSN address information to the PDF after the 
successful establishment of the secondary PDP context, i.e. with the report following the initial authorization decision. 

When the PDF detects that the binding information provided by the GGSN is not associated with an ongoing AF session 
at application layer, or is otherwise unable to authorise the binding information, the GGSN will receive a COPS 
decision message from the PDF carrying both an INSTALL and REMOVE decision. The "Request State" flag is not set 
within the REMOVE decision. The reason for the rejection is indicated by the INSTALL decision with an appropriate 
authorisation request failure reason. The GGSN shall reject the secondary PDP context activation with a corresponding 
error code, see annex D. The GGSN shall subsequently remove this state according to the REMOVE decision. For an 
initial authorisation request, the GGSN shall then send a COPS Delete Request State (DRQ) message to the PDF to 
remove the state in the GGSN and the PDF. 

When the GGSN sends an authorization request to the PDF but the PDF does not respond with the decision message or 
the communication between the GGSN and the PDF fails, the GGSN shall reject the secondary PDP context activation 
with the error code "Authorizing entity temporarily unavailable" (see annex D). 

5.1 .2 Modification of previously authorizecd PDP context 

The GGSN is responsible for notifying the PDF when a procedure of PDP context modification of a previously 
authorized PDP context is performed. A modification of a previously authorized PDP Context may occur for example 
when a new media component is added or when the codec change requires new resources. To authorise the PDP context 
modification the GGSN shall send an authorisation request to the PDF including the binding information received from 
the UE in the following cases: 

Requested QoS exceeds "Authorised QoS"; 

New binding information is received. 

The GGSN on receiving the PDP context modification request from the UE will verify the authorisation. If the GGSN 
does not have sufficient information to authorize the PDP context modification request then the GGSN shall interrogate 
the PDF for modification request authorisation. 

If the requested QoS is within the already "Authorized QoS" and the binding information is not changed, the GGSN 
need not send an authorization request to the PDF. 
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If the PDF does not respond with a decision message to an authorization request sent by the GGSN or the 
communication between the GGSN and the PDF fails, the GGSN shall reject the PDP context modification with the 
error code "Authorizing entity temporarily unavailable" (see annex D). 

When the GGSN receives an authorisation decision as response from the PDF containing a set of packet classifiers, the 
GGSN shall install this set of packet classifiers, removing any existing packet classifiers that are not included in this set. 

The GGSN is responsible for notifying the PDF, by sending a COPS Report State (RPT) message, when the procedure 
of the PDP context modification is performed in the following cases: 

Requested QoS maximum bit rate is kbit/s; 

Requested QoS maximum bit rate changes from kbit/s. 

5.1 .3 Session modification initiated decision 

The PDF may receive updated service information from the AF, conveying information about an AF session 
modification. An AF session modification may occur that modifies the media without adding or removing media 
component, for example, a change in the bandwidth for the media component, or a change to the port number. The 
GGSN will receive unsolicited authorisation decision from the PDF due to such modifications. 

When the GGSN receives an unsolicited authorisation decision from the PDF with updated QoS information, the GGSN 
shall update the stored authorised QoS. If the existing QoS of the PDP context exceeds the updated authorised QoS, the 
GGSN shall initiate a timer for the UE to modify the PDP context to decrease the QoS to within the authorised limit. At 
expiry of the timer, if the PDP context still exceeds the authorised QoS, the GGSN shall perform a network initiated 
PDP context modification to reduce the QoS to the authorised level. 

When the GGSN receives an unsolicited authorisation decision from the PDF, the GGSN shall also install the new set 
of packet classifiers, removing any existing packet classifiers that are not included in the new set. 

5.1 .4 PDP context deactivation 

The GGSN is responsible for notifying the PDF when a procedure of a PDP context deactivation is performed. In case 
of a PDP context deactivation, the GGSN shall inform the PDF of the bearer release related to the AF session(s) by 
sending a COPS Delete Request State (DRQ) message. 

When a revoke authorisation procedure is performed, the GGSN receives a decision message from the PDF for 
disabling the use of the "Authorised QoS" resources and deactivation of the PDP context associated with the binding 
information. The GGSN shall disable the use of the "Authorized QoS" resources. The GGSN shall initiate deactivation 
of the PDP context in case that the UE has not performed it yet. 

5.1 .5 Gate control operation 

Upon receiving a gate decision from the PDF, the GGSN shall enforce this decision on the user plane. For each gate 
contained in the gate decision the GGSN shall perform the specified command. In case of an "Approval of QoS 
Commit" command the GGSN shall open the corresponding gate. In case of a "Removal of QoS Commit" command the 
GGSN shall close the corresponding gate. 



5.1 .6 User plane operation 



The GGSN shall enforce the configuration of the policy based "gating" functionality according to additional 
authorisation information received from the PDF. 



£75/ 



3GPP TS 29.207 version 6.4.0 Release 6 1 9 ETSI TS 1 29 207 V6.4.0 (2005-06) 

The filter(s) and associated gate(s) are connected to the PDP contexts where SBLP appHes. For each such PDF context, 
the information received in the TFT is ignored. In the downhnk direction, packets are processed against each fiher in 
turn until a match is found. If a match is not found, packet processing shall then continue against filters installed from 
UE supplied TFTs for PDP contexts where SBLP is not applied. If a match is found against an SBLP supplied filter, the 
packet shall be processed according to the associated gate function. If the gate is open, the packet shall be passed to the 
UE on the associated PDP context. If the gate is closed, the packet shall be silently discarded. 

In the uplink direction, packets received on a PDP context with SBLP supplied filters shall be matched against those 
filters. If a match is found, the packet shall be passed if the gate associated with that filter is open. If the gate is closed, 
or if the packet does not match any of the packet filters, the packet shall be silently discarded. 

5.2 PDF 

5.2.1 SBLP decisions 

5.2.1 .1 SBLP authorisation decision 

The service information needed in the PDF to perform media authorization is provided by the AF via the Gq interface. 
The Gq interface between the AF and the PDF is specified in the 3GPP TS 29.209 [23]. 

The PDF should authorize all media components if no appUcation ID is available within the service information. 

The PDF stores the authorised policy information based on the service information received from the AF, and uses an 
Authorisation Token to identify this decision. 

The Authorisation Token is in the form of a Session Authorisation Data Policy Element as described in RFC 3520 [11]. 
The PDF shall include an AUTH_ENT_ID attribute containing the Fully Qualified Domain Name of the PDF and the 
SESSIONJD attribute. 

Upon receiving the bearer authorization request from the GGSN, the PDF shall authorize the request according to the 
stored service based local policy information for the session(s) identified by the binding information in the request. 

Decision on the binding information: 

The authorisation shall contain the decision on verifying the binding information. The PDF shall identify 
whether each set of the binding information indeed corresponds to an initiated AF session. If the 
corresponding AF session cannot be found for a set of binding information or the binding information 
contains invalid flow identifier(s), or the authorization token(s) has changed in an authorization modification 
request, the PDF shall enforce the rejection of this PDP context request by sending an INSTALL and 
REMOVE decision to the GGSN. The reason for the rejection is indicated by the INSTALL decision with the 
"noCorrespondingSession" reason in the Authorisation Request Failure Decision. If the PDF is otherwise 
unable to authorise the binding information, the INSTALL decision shall identify a general authorisation 
failure with the "authorisationFailure" of the request reason in the Authorisation Request Failure Decision. 

If the PDF is unable to get sufficient service information from the AF to authorise the binding information, 
the PDF may enforce the rejection of this PDP context request by sending an INSTALL and REMOVE 
decision to the GGSN. The reason for the rejection is indicated by the INSTALL decision with the 
"authorisationFailure" reason in the Authorisation Request Failure Decision. 

The authorization shall also contain the decision on the list of flow identifiers contained in the bearer 
authorisation request sent by the GGSN representing the IP flows of the media components intended to be 
carried in the same PDP Context. This decision shall verify that these IP flow(s) are indeed allowed to be 
carried in the same PDP Context. The PDF shall make this decision by comparing the list of flow identifiers 
contained in the bearer authorization request received from the GGSN to the media component grouping 
indication information received from the AF. 

In case the UE violates the AF level indication, and attempts to set up IP flows of multiple media components 
in a single PDP context despite of an indication that mandated separate PDP contexts, the PDF shall enforce 
the rejection of this PDP context request by sending an INSTALL and REMOVE decision to the GGSN. The 
reason for the rejection is indicated by the INSTALL decision with the "invalidBundling" reason in the 
Authorisation Request Failure Decision. 
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If the sets of binding information and the list of flow identifiers are successfully authorised (verified) as per 
the means described above, the PDF shall also communicate the authorisation details to the GGSN. 

If the PDF has already communicated authorisation for the same authorisation token(s) and flow identifier(s) 
to this (or another) GGSN, then the previous authorisation shall be revoked, and this revocation shall be 
communicated to the GGSN. 

The authorisation details contain the "Authorised QoS" and the packet classifier(s) of the IP flows. In case of 
an aggregation of multiple media components within one PDP context, the combination of the "Authorised 
QoS" information of the individual IP flows of the media components is provided as the "Authorised QoS". 

Based on the media direction information and the direction of the source provided by the AF, the PDF shall 
define the direction (upstream or downstream) of the "Authorised QoS" and the packet classifier(s). 

Packet classifier(s): 

The PDF shall derive the uplink and downlink packet classifiers from the IP addresses and port numbers for 
uplink and downlink IP flows provided by the AF as part of the service information. The PDF should not 
modify the address and port information received from the AF. 

The PDF shall send the destination address and the destination port number for each IP flow associated with 
the media component. 

- "Authorized QoS": 

The "Authorised QoS" information (consisting of maximum QoS Class and Data Rate) for IP flows of media 
is extracted from the service information received from the AF, e.g. from the media type information, 
bandwidth information and AF application ID. The PDF should select the QoS Class which is the highest 
class that can be used for the media. The PDF shall use an equal QoS Class for both the uplink and the 
downlink directions when both directions are used. 

The PDF shall derive the Data Rate value for the IP flow (s) from the service information , e.g. from 
contained bandwidth information, received form the AF. 

For non-real-time bearers the Data rate value shall be considered as the maximum value of the 'Maximum 
bitrate' parameter. 

In case of an aggregation of multiple media components within one PDP context, the PDF shall provide the 
"Authorised QoS" for the bearer as the combination of the "Authorised QoS" information of the individual IP 
flows of the media components. The QoS Class in the "Authorised QoS" for the bearer shall contain the 
highest QoS class amongst the ones applied for the individual IP flows and indicates the highest UMTS 
traffic class that can be applied to the PDP context. 

The Data Rate of the "Authorised QoS" for the bearer shall be the sum of the Data Rate values of the 
individual media IP flows of components and it is used as the maximum Data Rate value for the PDP context. 

- The detailed rules for calculating the "Authorized QoS" are specified in 3GPP TS 29.208 [18]. 

The PDF shall either include the gate enabling command as part of the authorisation decision, or the PDF may provide a 
separate decision for opening the gate, depending on the gating policy indicated as part of the service information 
received from the AF. 

The PDF shall send the AF charging identifier possibly provided by the AF as part of the authorisation decision to the 
GGSN. 

Upon receiving the modified service information from the AF, the PDF shall update the media authorization 
information for the session. The PDF may push this updated authorisation information to the GGSN. Under certain 
condition e.g. revoke of authorization, the PDF shall push the updated policy decision to the GGSN. If there are IP 
flows of several sessions under the same client handle, the PDF shall include the aggregate authorization information of 
all of these flows in the push decision. 
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5.2.1 .2 Session modification initiated decision 

The PDF may receive updated service information from the AF, conveying information about an AF session 
modification. A session modification may occur that modifies the media without adding or removing media 
components, for example, a change in the bandwidth for the media component, or a change to the port number. 

When there are updates to the media components which are currently authorised, the authorisation information (QoS, 
packet classifiers) may change. The updated information (QoS, packet classifiers) shall be pushed down to the GGSN 
using an unsolicited authorisation decision. 

However, if the update for media components which are currently authorised happens in the way of only changing a 
bidirectional media (Flow status "ENABLED") to unidirectional (Flow status "ENABLED-UPLINK" or "ENABLED- 
DOWNLINK"), then the updated QoS information shall not be pushed down to the GGSN. In this case "Removal of 
QoS commit" for the deactivated direction of the media shall be sent to the GGSN to close the gate in that direction. 



5.2.1 .3 SBLP revoke decision 

Upon release of an AF session of a given client handle (PDP context) the PDF shall send a revoke authorisation 
decision to the GGSN after an operator specific time. The revoke authorisation decision shall be sent for each handle 
(PDP context) related to the session as a separate decision to the GGSN corresponding to the previous SBLP 
authorisation decision. 

The timer for a pending session release shall be terminated if the PDF receives an indication on the deactivation (If 
there are no more media streams in a PDP context, the UE will remove this PDP) or new authorisation request with the 
same handle where the IP flow(s) of the released AF session have been removed (If at least one media stream is still 
present in the PDP context, the UE will modify this PDPcontext) of each of the PDP context(s) related to the released 

session. 

Additionally, when a media component which is bound to a PDP context is removed from an AF session and the UE 
has not performed the corresponding modification or deactivation of the PDP context within an operator specific time 
the PDF shall revoke the authorisation for the set of IP flows of the media components on that PDP context. 

The timer for a pending media component removal shall be terminated if the PDF receives either a new authorisation 
request with the same handle where the IP flows of that media component has been removed, or an indication of the 
termination of the PDP context. 

NOTE: The values of the timers for session termination and media component removal might be different, e.g. to 
allow for some more time for the required modification of the PDP context. 

If the PDF receives a request from a GGSN for the same authorisation token and flow identifier(s) that this (or another) 
GGSN was already communicated authorisation, then the previous authorisation shall be revoked, and this revocation 
shall be communicated to the GGSN. 

5.2.1.4 SBLP gate decision 

Updated service information received from the AF may demand that the PDF enables or disables IP flows. The PDF 
may send a gate decision whenever the status of a media component changes during the session (e.g. the media IP 
flow(s) of a media component is put on hold or resumed, or a media component is removed), or when a session is 
released and the related IP flows are removed from a PDP context that multiplexes IP flows from several sessions. The 
PDF shall not send a gate decision to the GGSN before it has sent the initial authorisation decision. If the initial 
authorisation decision has already been sent, the PDF shall send a gate decision to the GGSN to modify the status of 
one or several gate(s) on the user plane. The gate decision shall only contain the gate(s) for which the status was 
changed compared to the last authorisation or gate decision sent to the GGSN. The gate decision contains for each gate 
either the "Approval of QoS Commit" command to open the gate or the "Removal of QoS Commit" command to close 
the gate. The open gate command may either be a part of the authorization decision or the PDF may provide a separate 
decision with the "Approval of QoS Commit" command to open the gate. When a media IP flow is put on hold, the PDF 
may send the "Removal of QoS Commit" command to the GGSN to close the relevant gate - the possible RTCP gate 
shall be left open to keep the connection alive. The open gate command shall be used to resume the media from hold. 
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5.2.2 Support for SIP forking 



The PDF shall be able to handle SIP forking when SBLP is applied. For the IMS, forking can occur as specified in 

3GPPTS 23.228 [4]. 

5.2.2.1 Authorization of resources for forked responses 

As part of the service information, the PDF is informed by the AF if the second or subsequent SIP early dialogues are 
encountered within one SIP session. The AF provides separate service information for each SIP dialogue. The PDF 
shall allocate the same authorization token to all the early dialogues within one AF session. 

For the second, and any subsequent early dialogue, the PDF shall identify the existing authorization information for that 
session. The PDF shall authorize any additional media components and any increased QoS requirements for the 
previously authorized media components, as requested by the forked response. Thus, the QoS authorized for a media 
component shall be equal to the highest QoS requested for that media component by any of the forked responses. 
Authorization is done by the procedures for authorization request in subclauses 5.1.1 and 5.1.2 and SBLP decisions in 
subclause 5.2.1.1. 

Additional packet classifiers as required by the subsequent responses are sent to the GGSN by the session modification 
initiated decision specified in subclause 5.2.1.2. 

5.2.2.2 Updating the authorization information at the final answer 

As part of the service information, the PDF is informed by the AF when the first SIP early dialogue is progressed to 
establish the final SIP session. All the other early dialogues are terminated. The authorization information for the SIP 
session is updated to match the requirements of the remaining early dialogue only. Several actions may be needed in the 
PDF: 

• Only the packet classifiers and the QoS indicated by the first final answer shall remain authorized. This 
information shall be sent to the GGSN by the session modification initiated decision specified in 

subclause 5.2.1.2. This should be done without delay in order to reduce the risk for initial clipping of the media 
stream, and minimising possible misuse of resources. 

• The authorization for PDP contexts that were used only for the terminated early dialogues, shall be revoked as 
specified in subclause 5.1.4. 

• The PDF shall await new authorization requests for remaining PDP contexts with updated binding information to 
remove any media components that were authorized for the terminated early dialogues only. If necessary 

(i.e. after timeout), the authorization for these PDP contexts shall be revoked as specified in subclause 5.2.1.3. 

EXAMPLE: Assume that three forked responses for a certain media component indicate the bandwidths 

10 kbps, 30 kbps and 20 kbps, respectively. This media component will first be authorized for 
10 kbps and then upgraded to 30 kbps, which will be its final value for the early dialogue phase. If 
the first final answer corresponds to the third forked, provisional response, then QoS is finally 
downgraded to 20 kbps. 



6 Go protocol 

6.1 Protocol support 

6.1.1 TCP connection for COPS protocol 

The GGSN receives the PDF identifier received as part of the Authorization Token, during the secondary PDP context 
activation or PDP context modification procedure. The GGSN resolves the PDF IP address from the PDF identifier, 
which is in the form of a fully qualified domain name. 

If there is no existing TCP connection to the PDF, the GGSN shall establish a TCP connection for COPS interactions to 
the PDF. The GGSN shall use an existing TCP connection to the PDF, whenever present. 
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The TCP connection between the GGSN and the PDF may be pre-estabUshed by configuring the PDF addresses on the 
GGSN. 

All communication between the GGSN and the PDFs shall use a standardised Client-Type with a corresponding 
standardised PIB, as defined in annex B. 

The validity of the PDF may be ensured either by using a private DNS for resolving the PDF IP address or by 
configuring a list of allowed PDF IP addresses on the GGSN. 

6.1.2 COPS protocol 

The Go interface allows service-based local policy and QoS inter- working information to be "pushed" to or requested 
by the GGSN from a PDF. 

The COPS protocol supports a client/server interface between the GGSN and the PDF. The Go interface shall conform 
to the IETF COPS framework as a requirement and guideline for Stage 3 work. 

The COPS protocol allows both push and pull operations. For the purpose of the initial authorisation of QoS resources 
the pull operation shall be used. Subsequently the interactions between the PDF and the GGSN may use either pull or 
push operations. 

Policy decisions may be stored by the COPS client in a local policy decision point allowing the GGSN to make 
admission control decisions without requiring additional interaction with the PDF. 

The COPS client (PEP) can request a policy decision from the PDF triggered by a QoS signalling request. One PEP 
request may be followed by one or more asynchronous PDF decisions. Each of the decisions will allow the PDF to 
notify the PEP in the GGSN whenever necessary to change earlier decisions, generate errors etc. 

Protocol stack: IP, TCP and COPS. 

6.2 Basic COPS events/messages 

The Go interface supports event triggered information transfer between the GGSN and PDF 



6.2.1 Type of messages 



The COPS protocol supports several messages between GGSN and PDF. The message content is dependent on 
the type of COPS operation (e.g. Client-Open/Client- Accept/Client-Close, Request, Decision and Delete Request 

State). 

The Client Open, Client Accept, Client Close, Keep Alive, Synchronize State Request and Synchronize State 
Complete messages are used for setting up and maintaining the connection between the PDF and the GGSN. 

The following messages supported by the COPS layer for Go interface are used for the policy control operations: 

- Request (REQ) message from the GGSN to the PDF is used by the GGSN to request SBLP and QoS 
inter-working information. 

Decision (DEC) message from the PDF to the GGSN is a response to the Request message or an asynchronous 
notification from PDF to the GGSN whenever necessary in order to change earlier decisions, generate errors, etc. 

Report State (RPT) message from the GGSN to the PDF is used to communicate the success, failure or changes 
to the client state of the GGSN in carrying out the PDF's decision indicated in the Decision message. 

- Delete Request State (DRQ) message from the GGSN to the PDF indicates that the state identified by the client 
handle is no longer available/relevant and the corresponding state may be removed from the PDF. 



6.3 Go events/messages 



The UMTS -specific information is carried in specific COPS-PR objects, as defined in the 3GPP Go PIB that is given in 
annex B. 
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6.3.1 Event descriptions 



The Go Interface uses COPS-PR (RFC 3084 [8]) schematics and the 3GPP Go PIB. For COPS-PR to support the 
Outsourcing Model it is required to add a new 3GPP Go PIB with objects to: 

Describe the Triggering Event Handling. 

Describe the Outsourcing Event. 

Describe the Decision for the Outsourced Event. 

Describe the Termination of the Outsourced Event. 

Describe the resource used for the Outsourced Event. 

6.3.1 .1 Common Header, Client Type 

The COPS Client-type number for go3gpp is 0x8009 (Client type number assigned by lANA). 

6.3.1.2 Context Object 

The COPS Context Object is sent in the REQ and DEC messages. This object is used to indicate the triggering event. 
C-Num = 2, C-Type = 1 

12 3 



R-Type 


M-Type 



R-Type (Request Type Flag) 

0x08 for configuration request 
M-Type (Message Type) 

0x01 initial capability negotiation 

0x02 create event state 

0x03 update event state 

0x04 terminate event state 

6.3.1 .3 Client Specific Information (ClientSI) for outsourcing Operation 

The binding information consisting of the Authorization Token and flow identifier(s) received by the GGSN are 
encapsulated inside the Client Specific Information object of the COPS request message sent from the GGSN to the 
PDF. The PDF identifier is extracted from the token and used inside the GGSN to resolve the address of the actual PDF. 
However, from the Go message perspective, the token is treated as an opaque entity. 

6.3.1 .4 Conformance Section 

The conformance section indicates the PIB objects, i.e. provisioning classes (PRCs), that a PIB shall have to be 
conformant to 3GPP Go PIB. To be conformant to the 3GPP Go PIB, it is mandatory to have all the 3GPP Go PIB 
PRCs and the frwkPrcSupportGroup, frwkDeviceldGroup included from the Framework PIB ([15]). The supported 
PRCs are notified using these mandatory groups of PRCs from the Framework PIB. 

The following GGSN capabilities are notified to the PDF by indicating the corresponding PRCs: 

- Bearer authorisation capabilities: 
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The GGSN notifies the PDF that it supports bearer authorisation capabilities. The GGSN will provide the 
token(s) and flow identifier(s) in the REQ for verifying the binding information and the grouping of the 
media flows by the PDF. The go3gppAuthReqEventGroup together with the go3gppBindingInfoGroup and 
the go3gppFlowIdGroup are used for this purpose. 

Furthermore, the GGSN will enforce any requested or unrequested decision for the authorisation of GPRS 
and IP resources. If the authorisation at the PDF fails the go3gppAuthReqFailDecGroup is used to give some 
information on the reason of failure to the GGSN. The go3gppAuthReqDecGroup together with the 
go3gppAuthReqDirDecGroup are used in case of a successful authorisation at the PDF. This also includes 
the following capabilities: 

"Authorised QoS" capabilities: 

The GGSN notifies the PDF that it is capable to enforce the combined "Authorised QoS" for the 
bearer. The go3gppQosGroup is used for this purpose. 

Gating capabilities: 

The GGSN notifies the PDF that it is capable to enforce the gating functionality. The 
go3gppGateGroup together with the frwkBaseFilterGroup and the frwklpFilterGroup are used for this 
purpose. 

Indication of device capabilities and device limitations: 

The GGSN informs the PDF that it is able to notify its device capabilities and device limitations. The 
go3gppAuthReqCapGroup and the go3gppAuthReqDecCapGroup are used for this purpose. 

Open /close the gate capabilities: 

The GGSN informs the PDF that it is capable to enforce a separate decision on opening the gate for the 
authorised media flow and it is capable to enforce a separate decision from the PDF regarding disabling of 
the gate. The go3gppGateDecGroup together with the go3gppGateGroup are used for this purpose. 

Revoke media authorisation capabilities: 

The GGSN notifies the PDF that it is capable to enforce the revoke authorisation for GPRS and IP resources 
decision from the PDF. No PRCs are required to indicate this capability. 

Charging co-ordination: 

The GGSN informs the PDF that it is capable to send GCID(s) and GGSN address to the PDF. The 
go3gppReportGroup together with the go3gppRprtGPRSChrgInfoGroup are used for this purpose. 

The GGSN informs the PDF that it is capable to receive ICID(s) from the PDF. The 
go3gppAuthReqDecGroup together with the go3gppIcidGroup are used for this purpose. 

Indication of QoS modifications to kbps and from kbps: 

The GGSN informs the PDF that it is able to notify when the maximum bit rate for the PDP context is 
modified to kbps or that the maximum bit rate for the PDP context is changed from kbps. The 
go3gppReportGroup together with the go3gppRprtUsageGroup are used for this purpose. 

Indication of bearer release: 

The GGSN notifies the PDF that it is capable to notify when the previously authorised GPRS and IP 
resources are released, i.e. PDP context is deactivated. No PRCs are required to indicate this capability. 

COPS-PR specific capabilities: 

The GGSN informs the PDF that it supports the following COPS-PR (RFC 3084 [8]) specific capabilities: 

Outsourcing capability: 

The GGSN informs the PDF that it supports the outsourcing model. The 
go3gppAuthReqHandlerGroup is used for this purpose. 
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6.3.1 .5 Reporting of Device Capabilities and Device Limitations 

The functionality of reporting of device capabilities and device limitations is as described in RFC 3084 [8]. In addition, 
the following shall apply. 

The configuration request message serves as a request from the GGSN to the PDF and includes provisioning client 
information to provide the PDF with client-specific configuration or capability information about the GGSN. The 
capability information to be exchanged could include additional PIB objects supported by the GGSN which are part of 
the capability section. If no value information is exchanged then the default value will be used as if it had been 
exchanged. This information from the client assists the server in deciding what types of policy the GGSN can install 
and enforce. 

The following GGSN capabilities and limitations may be provided in the configuration request message: 

Indication of the maximum number of binding information: 

The GGSN may notify the PDF how many binding information the GGSN is able to send with an 
Authorization_Request. 

Indication of the maximum number of Flow identifiers: 

The GGSN may notify the PDF how many Flow identifiers the GGSN is able to send with an 
Authorization_Request. 

Indication of the maximum number of ICIDs: 

The GGSN may notify the PDF how many ICIDs the GGSN is able to receive with an 
Authorization_Decision. 



The device capabilities information exchanged by the initial messages shall be stored in the PDF. 

6.3.1.6 Initial Go Policy Provisioning 

The functionality of initial Go policy provisioning is as described in RFC 3084 [8]. In addition, the following shall 
apply: 

The DEC message is sent from the PDF to the GGSN in response to the REQ message received from the GGSN. 
The Client Handle shall be the same as that received in the corresponding REQ message. 

The DEC message is sent as an immediate response to a configuration request with the solicited message flag set 
in the COPS message header. The PDF shall also inform the GGSN what types of events shall trigger policy 
control requests over the Go interface. 

The R-type = 0x08 for configuration request is used here and M-type = 0x01 initial capability negotiation is used 
here. 



6.3.2 Message description 



The following messages and events are available on the Go interface (after the initial policy provisioning described in 
subclause 6.3.1.5): 

- Authorisation_Request (REQ) (GGSN^PDF): 

This event allows the GGSN to request authorisation data from the PDF. It contains the following information: 

Client Handle; 

Binding Information. 
The R-type = 0x08 for configuration request is used here and M-type = 0x02 create event state is used here. 

- Authorisation_Decision (DEC)(PDF^GGSN), contains an INSTALL decision: 
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This event provides the GGSN with the relevant authorisation data. The event contains the following 
information: 

Client Handle; 

ICID(s) (only in the initial Authorisation_Decision). Only one ICID is transferred in this Release. The form 
of the ICID is defined in 3GPP TS 32.225 [21]; 

Unidirectional set (this parameter shall appear once for each direction (uplink and downlink)): 

Direction indicator; 
- "Authorised QoS"; 

Gate description (this parameter shall appear once for each required gate for this direction): 

Filter Specification - The information about the authorised IP end points addresses and ports is 
detailed below. The Filter Specification parameters are: 

Source IP address; 

- Destination IP address; 
Source ports; 

- Destination ports; 

- Protocol ID. 

The Source and Destination ports are described with a range consisting of a minimum and 
maximum value. If only one port is authorised, the minimum value and maximum value of the 
range are identical. 

A filter specification describing more than one IP flow shall be only used in case of identical 
Protocol IDs, IP addresses and successive port numbers (e.g. RTP and RTCP IP flow of a media 
component). Furthermore, the gate status of all IP flows described by this filter specification shall 
be identical, too. 

The Base and IP Filter definitions from the IETF Framework PIB [15] shall be used in the 3GPP 
Go PIB to represent the filter specification. Only a subset of the available filter attributes shall be 
used. The attributes frwklpFilterDscp, and frwklpFilterFlowId in the filter description shall have 
their values set to -1, indicating a "match-all" wildcard condition, in effect a "not used" condition. 
The attribute frwkBaseFilterNegation shall have its value set to "false" to indicate not using 
negation, in effect a "not used" condition. The GGSN shall ignore them if they are set otherwise. 
Wildcarding of filter elements is detailed in Annex B. 

Gate status (opened/closed) 

The R-type = 0x08 for configuration request is used here and M-type = 0x02 create event state is used here. 

- Authorisation_Failure (DEC) (PDF^GGSN), contains an INSTALL and a REMOVE decision: 

This event provides the GGSN with an indication of an authorisation failure, and may carry additional reason 
details. The event contains the following information: 

Client Handle; 

Authorisation failure (including any provided reason information). 
The R-type = 0x08 for configuration request is used here and M-type = 0x04 terminate event state is used here. 
The COPS Decision Flags object 0x02 ("Request-State" flag) shall not be set for the REMOVE decision. 

- Gate Decision (DEC) (PDF^GGSN), contains an INSTALL decision: 
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The Gate Decision indicates to the GGSN the new status of the gate(s) estabhshed for a client handle (PDP 
context). The gate status indicates to the GGSN that the gate shall be opened or closed. Only the gate(s) for 
which the status is changed are indicated by this event. The event contains the following information: 

Client Handle; 

Unidirectional set (this parameter shall appear once for each direction for which gates are being updated 
(uplink and/or downlink)): 

- Direction indicator; 

Gate description (this parameter shall appear once for each gate to be modified for this direction) : 

Filter Specification - The information about the authorised IP end points addresses and ports is 
detailed below. The Filter Specification parameters are: 

Source IP address; 

- Destination IP address; 
Source ports; 
Destination ports; 

- Protocol ID. 

The Source and Destination ports are described with a range consisting of a minimum and 
maximum value. If only one port is authorised, the minimum value and maximum value of the 
range are identical. 

A filter specification describing more than one IP flow shall be only used in case of identical 
Protocol IDs, IP addresses and successive port numbers (e.g. RTP and RTCP IP flow of a media 
component). Furthermore, the gate status of all IP flows described by this filter specification shall 
be identical, too. 

The Base and IP Filter definitions from the IETF Framework PIB [15] shall be used in the 3GPP 
Go PIB to represent the filter specification. Only a subset of the available filter attributes shall be 
used. The attributes frwklpFilterDscp, and frwklpFilterFlowId in the filter description shall have 
their values set to -1, indicating a "match-all" wildcard condition, in effect a "not used" condition. 
The attribute frwkBaseFilterNegation shall have its value set to "false" to indicate not using 
negation, in effect a "not used" condition. The GGSN shall ignore them if they are set otherwise. 
Wildcarding of filter elements is detailed in Annex B. 

Gate status (opened/closed) 

NOTE: The opening of the gate may occur at the same time / be part of the authorisation decision event. 

The R-type = 0x08 for configuration request is used here and M-type = 0x03 update event state is used here. 

- Report (RPT) (GGSN^PDF): 

The GGSN sends a COPS RPT message as a response to a decision (DEC) message back to the PDF 
reporting that it enforced or not the Authorisation_Decision or the Authorization_Failure_Decision 
(Authorization_Report) or the Gate_Decision (Gate_Report). 

The events contain the following information: 

Client Handle; 

Success / Failure. 
In addition, the Authorization_report of the initial Authorisation_Decision includes: 

- GCID; 

- GGSN address. 
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Report of state changes: 

The GGSN sends the report of state change message to the PDF reporting that the maximum bit rate for the 
PDP context is modified to kbps or that the maximum bit rate for the PDP context is changed from kbps. 

The event contains the following information: 

- Client Handle; 

- Maximum bit rate (set to kbps / changed from kbps). 

- Delete Request State (DRQ) (GGSN^PDF): 

The GGSN informs the PDF via the delete request state message, that the PDP context is deactivated and the 
request state identified by the client handle is no longer available/relevant at the GGSN, so the corresponding 
state shall also be removed at the PDF. 

The DRQ message includes the reason why the request state was deleted. 

The event contains the following information: 

Client Handle; 

Reason code: value 4: 

Value 4 "Tear": This value is used when the PDP context has been deactivated as a result from normal PDP 
context signalling handling. 

Value 7 "Insufficient bearer resources": This value is used when the PDP context has been deactivated due to 
insufficient bearer resources at the GGSN. 

- Remove_Decision (DEC) (PDF^GGSN): 

The PDF uses the Remove_Decision to inform the GGSN that the PDF revokes the authorized resources for the 
client handle (PDP context). The Remove_Decision is a specific Decision message with the COPS Decision 
Flags object set to 0x02 ("Request-State" flag) and the Command-Code set to "REMOVE"; see IETF RFC 3084 
[8]. 

The event contains the following information: 

Client Handle. 

The R-type = 0x08 for configuration request is used here and M-type = 0x04 terminate event state is used here. 

6.4 Go data 

The detailed data description is provided in annex B. 

6.5 Security Considerations 

The security mechanisms described in COPS (RFC 2748 [7]) and COPS-PR (RFC 3084 [8]) should be re-used in 3GPP. 
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Annex A: 
(Void) 



£75/ 



3GPP TS 29.207 version 6.4.0 Release 6 



31 



ETSI TS 129 207 V6.4.0 (2005-06) 



Annex B (normative): 
SGPPGoPIB 

G03GPP-PIB PIB-DEFINITIONS ::= BEGIN 

IMPORTS 

Unsigned32, Integer32, MODULE-IDENTITY, 
MODULE-COMPLIANCE, OBJECT-TYPE, OBJECT-GROUP 

FROM COPS-PR-SPPI — Defined in RFC 3159 [9] 

Instanceld, Prid 

FROM COPS-PR-SPPI-TC — Defined in RFC 3159 [9] 

zeroDotZero FROM SNMPv2-SMI 



InetAddress, InetAddressType, 
InetAddressPref ixLength 

FROM INET-ADDRESS-MIB; 



Defined in RFC 3291 [19] 



go3gppPib MODULE-IDENTITY 

SUBJECT-CATEGORIES { go3gpp (0x8009) } 

LAST-UPDATED "200305240000Z" 



ORGANIZATION 
CONTACT- INFO 



— Go 3GPP COPS Client Type 



"3GPP TSG CN WG3" 

"Kwok Ho Chan 
Nortel Networks 
600 Technology Park Drive 
Billerica, MA 01821 USA 
Phone: +1 978 288 8175 
Email: khchan@nortelnetworks.com 



Louis-Nicolas Hamer 
Nortel Networks 
PO Box 3511 Station C 
Ottawa, Ontario 
Canada, KlY 4H7 
Phone: +1 613 768 3409 
Email : nhamer@nortelnetworks . com" 
DESCRIPTION 

"A PIB module containing the set of provisioning 
classes that are required for support of policies for 
3GPP's GO interface. Release 5." 
REVISION "200305240000Z " 
DESCRIPTION 

"The 3GPP Go PIB for release 5 
Annex B of 3GPP TS 29.207 v5 . 4 . . " 



(13 6 14 1 10415 1 1 } 



full specification of object ID tree. 

— The final syntax should be ( 3gpp_pib 1 } 

— With imports from the document that shows 

— that 3gpp_pib means ( 1.3.6.1.4.1.10415.1 



The root OID for PRCs in the 3GPP GO PII 



go3gppCapabilityClasses OBJECT IDENTIFIER 

go3gppEventHandlerClasses OBJECT IDENTIFIER 

go3gppEventClasses OBJECT IDENTIFIER 

go3gppEventInfoClasses OBJECT IDENTIFIER 

go3gppReqInfoClasses OBJECT IDENTIFIER 

go3gppDecInfoClasses OBJECT IDENTIFIER 

go3gppReportClasses OBJECT IDENTIFIER 

go3gppConformance OBJECT IDENTIFIER 



go3gppPib 1 } 
go3gppPib 2 } 
go3gppPib 3 } 
go3gppPib 4 } 
go3gppEvent Inf oClasses 
go3gppEvent Inf oClasses 
go3gppPib 5 } 
go3gppPib 6 } 



Capability and Limitation Policy Rule Classes 
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3GPP GO Capability Table 



go3gppAuthReqCapTable OBJECT-TYPE 

SYNTAX SEQUENCE OF GoSgppAuthReqCapEnt ry 

PIB-ACCESS notify 
STATUS current 

DESCRIPTION 

"The 3GPP Go Authorization Request Capability PRO." 
::= { goSgppCapabilityClasses 1 } 



go3gppAuthReqCapEntry OBJECT-TYPE 

SYNTAX GoSgppAuthReqCapEntry 

STATUS current 

DESCRIPTION 

"An instance of the goSgppAuthReqCap class identifies a 
specific PRO and associated attributes as supported 
by the device . " 

PIB-INDEX { go3gppAuthReqCapPrid } 

UNIQUENESS { } 

::= { goSgppAuthReqCapTable 1 } 



Go3gppAuthReqCapEntry ::= SEQUENCE { 

goSgppAuthReqCapPrid Instanceld, 

go SgppAuthReqCapBinding Infos Unsigned32, 
go3gppAuthReqCapFlowIds Unsigned32 

} 



go3gppAuthReqCapPrid OBJECT-TYPE 

SYNTAX Instanceld 

STATUS current 

DESCRIPTION 

"An arbitrary integer index that uniquely identifies an 
instance of the go3gppAuthReqCap class." 

::= { go3gppAuthReqCapEntry 1 } 



go3gppAuthReqCapBindingInfos OBJECT-TYPE 

SYNTAX Unsigned32 

STATUS current 

DESCRIPTION 

"Indication of the maximum number of Binding Information 
the PEP can send with each Authorization Request. 
The value of zero indicates limit is not specified." 

DEFVAL { } 

::= { go3gppAuthReqCapEntry 2 } 



go3gppAuthReqCapFlowIds OBJECT-TYPE 
SYNTAX Unsigned32 

STATUS current 

DESCRIPTION 

"Indication of the maximum number of Flow identifiers the PEP can 

send with each Authorization Request. 

The value of zero indicates limit is not specified." 
DEFVAL { } 
::= { go3gppAuthReqCapEntry 3 } 



Go 3GPP Authorization Request Decision Capabilities 



go3gppAuthReqDecCapTable OBJECT-TYPE 

SYNTAX SEQUENCE OF Go3gppAuthReqDecCapEnt ry 

PIB-ACCESS notify 
STATUS current 

DESCRIPTION 

"The 3GPP Go Authorization Request Decision Capability PRC. 
::= { go3gppCapabilityClasses 2 } 
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goSgppAuthReqDecCapEntry OBJECT-TYPE 

SYNTAX GoSgppAuthReqDecCapEntry 

STATUS current 

DESCRIPTION 

"An instance of the goSgppAuthReqDecCap class identifies a 
specific PRC and associated attributes as supported 
by the device . " 

PIB-INDEX { go3gppAuthReqDecCapPrid } 

UNIQUENESS { } 

::= { goSgppAuthReqDecCapTable 1 } 



GoSgppAuthReqDecCapEntry ::= SEQUENCE { 

goSgppAuthReqDecCapPrid Instanceld^ 

goSgppAuthReqDecCapIcids Unsigned32 

} 

goSgppAuthReqDecCapPrid OBJECT-TYPE 

SYNTAX Instanceld 

STATUS current 

DESCRIPTION 

"An arbitrary integer index that uniquely identifies an 
instance of the goSgppAuthReqDecCap class." 

::= { goSgppAuthReqDecCapEntry 1 } 

goSgppAuthReqDecCapIcids OBJECT-TYPE 

SYNTAX UnsignedS2 

STATUS current 

DESCRIPTION 

"Indication of the maximum number of Icid possible 

in a single Authorization Request Decision. 

The value of zero indicates limit is not specified." 

DEFVAL { } 

::= ( goSgppAuthReqDecCapEntry 2 } 



— Component Limitations Table 

— This table supports the ability to export information 

— detailing provisioning class/attribute implementation limitations 

— to the policy decision function. This Component Limitations Table 

— shall be implementation dependant and does not need to be standardized. 



SGPP GO Event Handler Provisioning Classes 

PRCs sent from PDF to PEP for indicating how to handle each 
kind of event that require actions by the GO interface. 

For SGPP Release 5, PRCs for Event Handling of Authorization 
Request containing Binding Information, Flow identifiers, and QoS is 
specified. 



SGPP GO Authorization Request Event Handler Provisioning Table 



goSgppAuthReqHandlerTable OBJECT-TYPE 

SYNTAX SEQUENCE OF GoSgppAuthReqHandlerEnt ry 

PIB-ACCESS install 

STATUS current 

DESCRIPTION 

"PRC from PDF to PEP carried by COPS DEC messages 

indicating GO actions to take at the GGSN when an Authorization 
Request Event is detected by the GGSN. An example of an 
Authorization Request Event is the receive of a PDP Context message. 

::= ( goSgppEventHandlerClasses 1 } 



goSgppAuthReqHandlerEntry OBJECT-TYPE 
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SYNTAX Go3gppAuthReqHandlerEntry 

STATUS current 

DESCRIPTION 

"An instance of the goSgppAuthReqHandler class sent by the PDF to 
the PEP what the PEP should send upon detection of an Authorization 
Request Event . " 

PIB-INDEX { goSgppAuthReqHandlerPrid } 

UNIQUENESS { goSgppAuthReqHandlerEnable, 

goSgppAuthReqHandlerBindingInf o 
} 

::= { go3gppAuthReqHandlerTable 1 } 

GoSgppAuthReqHandlerEntry ::= SEQUENCE { 

goSgppAuthReqHandlerPrid Instance Id, 
goSgppAuthReqHandlerEnable INTEGER, 
goSgppAuthReqHandlerBindingInf o UnsignedS2 



goSgppAuthReqHandlerPrid OBJECT-TYPE 
SYNTAX Instanceld 

STATUS current 

DESCRIPTION 

"An arbitrary integer index that uniquely identifies an 

instance of this class." 
::= ( goSgppAuthReqHandlerEntry 1 } 



goSgppAuthReqHandlerEnable OBJECT-TYPE 
SYNTAX INTEGER { 

enable (1) , 
disable (2) 
} 
STATUS current 

DESCRIPTION 

"Controls the usage of SGPP Authorization Request Events 
to trigger COPS requests to PDF on the go interface." 
DEFVAL { enable } 
::= ( goSgppAuthReqHandlerEntry 2 } 



goSgppAuthReqHandlerBindinglnfo OBJECT-TYPE 
SYNTAX UnsignedS2 
STATUS current 

DESCRIPTION 

"Indication of the maximum number of Binding Information 

be associated with a each Authorizating Request. 

The value of zero indicates policy control does not impose 

any limit . " 
DEFVAL { } 
::= { goSgppAuthReqHandlerEntry S } 



— SGPP GO Event Classes 

— PRCs from PEP to PDF carried by COPS REQ messages 

— indicating the detection of specific events in the GGSN. 

— Information required for PDF to make decision on behave 

— of GGSN is also defined here to be carried by REQ messages. 



— SGPP GO Authorization Request Event Table 

goSgppAuthReqEvent Table OBJECT-TYPE 

SYNTAX SEQUENCE OF GoSgppAuthReqEventEnt ry 

PIB-ACCESS notify 
STATUS current 

DESCRIPTION 

"PRC for indication of Authorization Request Event 

and its relevant information. 

Sent by PEP to PDF upon receive of an Authorization 

Request. Using COPS REQ message." 
::= { goSgppEventClasses 1 } 
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go3gppAuthReqE vent Entry OBJECT-TYPE 

SYNTAX Go3gppAuthReqEventEntry 

STATUS current 

DESCRIPTION 

"An entry in the Authorization Request Event Table 
describe a single Event sent by the PEP to the PDF. 

PIB-INDEX { goSgppAuthReqEventPrid } 

UNIQUENESS { } 

::= ( go3gppAuthReqEventTable 1 } 



GoSgppAuthReqEventEntry ::= SEQUENCE { 

goSgppAuthReqEventPrid Instanceld, 
goSgppAuthReqEventBinding Infos Prid 

} 



goSgppAuthReqEventPrid OBJECT-TYPE 

SYNTAX Instanceld 

STATUS current 

DESCRIPTION 

"An arbitrary integer index that uniquely identifies an 
instance of the goSgppAuthReqEvent class." 

::= { goSgppAuthReqEventEntry 1 } 



goSgppAuthReqEventBindinglnfos OBJECT-TYPE 

SYNTAX Prid 

STATUS current 

DESCRIPTION 

"References the first of a list of goSgppBindinglnfo 
class instances that are associated with this 
Authorization Request Event. 

A value of zeroDotZero indicates there are no 
goSgppBindingInf o class instance associated with 
this Authorization Event." 

::= ( goSgppAuthReqEventEntry 2 } 



SGPP Go Event Request Info Classes 



— SGPP GO Binding Information Table 

goSgppBindingInf oTable OBJECT-TYPE 

SYNTAX SEQUENCE OF GoSgppBindingInf oEntry 

PIB-ACCESS notify 

STATUS current 

DESCRIPTION 

"PRC representing Binding Information. 

Sent by PEP to PDF as part of an Authorization 

Request. In a COPS REQ message." 

::= { goSgppReqInfoClasses 1 } 



goSgppBindinglnfoEntry OBJECT-TYPE 

SYNTAX GoSgppBindinglnfoEntry 

STATUS current 

DESCRIPTION 

"An entry in the Binding Information Table 

describing a single Binding Info. 

Each entry is referenced by goSgppAuthReqEventBindinglnfos 

or goSgppBindingInf oNext . " 
PIB-INDEX { goSgppBindinglnfoPrid } 
UNIQUENESS { } 
::= ( goSgppBindingInf oTable 1 } 



GoSgppBindinglnfoEntry ::= SEQUENCE { 

goSgppBindinglnfoPrid Instanceld^ 

goSgppBindinglnfoToken OCTET STRING, 
goSgppBindinglnfoFlowIds Prid, 
goSgppBindingInf oNext Prid 
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go3gppBindingInfoPrid OBJECT-TYPE 

SYNTAX Instanceld 

STATUS current 

DESCRIPTION 

"An arbitrary integer index that uniquely identifies an 
instance of the goSgppBindingInf o class." 

::= ( goSgppBindingInf oEntry 1 } 



go3gppBindingInfoToken OBJECT-TYPE 

SYNTAX OCTET STRING 

STATUS current 

DESCRIPTION 

"The Authorization Token associated with this 
instance of the goSgppBindinglnfo class. 
Each Binding Information must have a Token." 

::= ( goSgppBindingInf oEntry 2 } 



goSgppBindingInf oFlowIds OBJECT-TYPE 
SYNTAX Prid 

STATUS current 

DESCRIPTION 

"References the first of a list of Flowlds associated 

with this instance of goSgppBindinglnfo class. 

This is the anchor of a list of goSgppFlowIdEntry 

Instances . 

A value of zeroDotZero indicates an empty list which 

is an error condition." 
DEFVAL { zeroDotZero } 
::= ( goSgppBindingInf oEntry S } 



goSgppBindingInf oNext OBJECT-TYPE 

SYNTAX Prid 

STATUS current 

DESCRIPTION 

"References the next of a list of goSgppBindinglnfo 
instances associated with an Authorization Request. 
A value of zeroDotZero indicates this is the last of 
a list of goSgppBindinglnfo instances associated with 
an Authorization Request." 

DEFVAL { zeroDotZero } 

::= { goSgppBindingInf oEntry 4 } 



— SGPP Go Authorization Request FlowID Table 

goSgppFlowIdTable OBJECT-TYPE 

SYNTAX SEQUENCE OF GoSgppFlowIdEntry 

PIB-ACCESS notify 
STATUS current 

DESCRIPTION 

"Represents the collection of FlowIDs." 
::= { goSgppReqInfoClasses 2 } 



goSgppFlowIdEntry OBJECT-TYPE 

SYNTAX GoSgppFlowIdEntry 

STATUS current 

DESCRIPTION 

"Each entry describes a single FlowID." 
PIB-INDEX { goSgppFlowIdPrid } 
UNIQUENESS { } 
::= { goSgppFlowIdTable 1 } 



GoSgppFlowIdEntry ::= SEQUENCE { 

goSgppFlowIdPrid Instanceld, 
goSgppFlowIdFlowId UnsignedS2, 
goSgppFlowIdNext Prid 

} 



goSgppFlowIdPrid OBJECT-TYPE 
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SYNTAX Instanceld 
STATUS current 

DESCRIPTION 

"An arbitrary integer index that uniquely identifies an 

instance of the goSgppFlowId class." 
: := ( go3gppFlowIdEntry 1 } 

go3gppFlowIdFlowId OBJECT-TYPE 
SYNTAX Unsigned32 
STATUS current 

DESCRIPTION 

"The Flowld itself." 
: := ( goSgppFlowIdEntry 2 } 

go3gppFlowIdNext OBJECT-TYPE 
SYNTAX Prid 

STATUS current 

DESCRIPTION 

"References the next Flowld in the list associated with the 

same Binding Information of an Authorization Request. 

This points to a list of goSgppFlowIdEntry Instances. 

A value of zeroDotZero indicates end of the list." 
DEFVAL { zeroDotZero } 
::= { goSgppFlowIdEntry 3 } 



— 3GPP Go Authorization Request Decisions 

— PRCs for carrying the Event Decision send from PDF to PEP, 

— carried by the COPS DEC message. 

— These PRCs include support for Gates/Filters, QoS, ICIDs. 



Failure Decisions can be defined by use of COPS-PR DEC message 
containing first an install decision (with objects indicating 
what failed and some indication to the GGSN how to react to this 
Error Decision), and second a remove decision (for cleanup of 
the installed Error Decision Object) . 



Failures indicated by PDF to GGSN 
Authorization Failure 



Authorization Request Failure Decision Table 

go3gppAuthReqFailDecTable OBJECT-TYPE 

SYNTAX SEQUENCE OF Go3gppAuthReqFailDecEnt ry 

PIB-ACCESS install 
STATUS current 

DESCRIPTION 

"The Authorization failure Table. Indicates failures decisions to the PEP. 
::= { go3gppDecInfoClasses 1 } 

go3gppAuthReqFailDecEntry OBJECT-TYPE 

SYNTAX Go3gppAuthReqFailDecEntry 

STATUS current 

DESCRIPTION 

"Each go3gppAuthReqFailDecEntry is per request." 
FIB-INDEX { go3gppAuthReqFailDecPrid } 
UNIQUENESS { } 
::= { go3gppAuthReqFailDecTable 1 } 

Go3gppAuthReqFailDecEntry ::= SEQUENCE { 

go3gppAuthReqFailDecPrid Instanceld, 

go3gppAuthReqFailDecReason INTEGER 
} 

go3gppAuthReqFailDecPrid OBJECT-TYPE 
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SYNTAX Instanceld 

STATUS current 

DESCRIPTION 

"An arbitrary integer index that uniquely identifies an 
instance of the goSgppAuthReqFailDec class." 

::= { goSgppAuthReqFailDecEntry 1 } 



go3gppAuthReqFailDecReason OBJECT-TYPE 
SYNTAX INTEGER { 

noCorrespondingSession (1), 
InvalidBundling (2), 
authorizationFailure (3) 
} 
STATUS current 

DESCRIPTION 

"Reason for Auth Request Failure Decision given by PDF: 



noCorrespondingSession: 



No corresponding session was found 
by the PDF 



InvalidBundling: 



In case the UE violates the AF level indication 

and attempts to set up multiple AF media components 

in a single PDP context despite of an indication that 

mandated separate PDP contexts or if the list 

of f lowidentif iers contained in the bearer authorization 

request doesn't match with the grouping indication 

information the PDF has received from the AF . 



authorizationFailure : 



The PDF is unable to authorise the binding information. 
This is a generic failure indication that can be used 
if the actual reason is not any of the other specified 
reasons . " 



{ goSgppAuthReqFailDecEntry 2 } 



— Authorization Request Decision Table 

go3gppAuthReqDecTable OBJECT-TYPE 

SYNTAX SEQUENCE OF GoSgppAuthReqDecEnt ry 

PIB-ACCESS install 
STATUS current 

DESCRIPTION 

"The Authorization Request Decision Table. " 
::= { go3gppDecInfoClasses 2 } 



goSgppAuthReqDecEntry OBJECT-TYPE 

SYNTAX GoSgppAuthReqDecEntry 

STATUS current 

DESCRIPTION 

"Each go3gppAuthReqDecEntry is per Authorization Request. 
PIB-INDEX { go3gppAuthReqDecPrid } 
UNIQUENESS { } 
::= { goSgppAuthReqDecTable 1 } 



GoSgppAuthReqDecEntry ::= SEQUENCE { 

go3gppAuthReqDecPrid Instanceld, 
go3gppAuthReqDecIcids Prid, 
goSgppAuthReqDecDirDecs Prid 

} 



go3gppAuthReqDecPrid OBJECT-TYPE 

SYNTAX Instanceld 

STATUS current 

DESCRIPTION 

"An arbitrary integer index that uniquely identifies an 
instance of the goSgppAuthReqDec class." 

::= ( goSgppAuthReqDecEntry 1 } 



goSgppAuthReqDec I cids OBJECT-TYPE 
SYNTAX Prid 
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STATUS current 

DESCRIPTION 

"References the first of a list of IcIDs associated 

with this instance of goSgppAuthReqDec class. 

There should be one IcID on this list for each Binding 

Information in the corresponding Authorization Request. 

A value of zeroDotZero indicates an empty list and there 

is no IcID change associated with this Authorization Request 

Decision . " 

DEFVAL { zeroDotZero } 

::= ( go3gppAuthReqDecEntry 2 } 



goSgppAuthReqDecDirDecs OBJECT-TYPE 

SYNTAX Prid 

STATUS current 

DESCRIPTION 

"References the first of a list of Directional Decisions 
associated with this instance of goSgppAuthReqDec class. 
There should be at least one and at most two Directional 
Decisions per Authorization Request Decision. 
Hence a value of zeroDotZero is illegal." 

::= { goSgppAuthReqDecEntry 3 } 



3GPP Go ICID Table 

goSgppIcidTable OBJECT-TYPE 

SYNTAX SEQUENCE OF GoSgppIcidEnt ry 

PIB-ACCESS install 
STATUS current 

DESCRIPTION 

"Represents the collection of ICID entries'' 
::= { goSgppDecInfoClasses 3 } 



goSgppIcidEntry OBJECT-TYPE 

SYNTAX Go3gppIcidEntry 

STATUS current 

DESCRIPTION 

"Represents the ICID Entry" 
PIB-INDEX { goSgppIcidPrid } 
UNIQUENESS { go3gppIcidValue } 
::= { goSgppIcidTable 1 } 



Go3gppIcidEntry ::= SEQUENCE { 

go3gppIcidPrid Instanceld, 

goSgppIcidValue OCTET STRING, 

goSgppIcidNext Prid 



go3gppIcidPrid OBJECT-TYPE 

SYNTAX Instanceld 

STATUS current 

DESCRIPTION 

"An arbitrary integer index that uniquely identifies an 

instance of the goSgppIcid class." 
::= { go3gppIcidEntry 1 } 



goSgppIcidValue OBJECT-TYPE 

SYNTAX OCTET STRING 

STATUS current 

DESCRIPTION 

"The ICID itself. " 
::= { goSgppIcidEntry 2 } 



go3gppIcidNext OBJECT-TYPE 

SYNTAX Prid 

STATUS current 

DESCRIPTION 

"References the next goSgppIcidEntry of a list of ICIDs 
associated with this instance of goSgppAuthReqDec class. 
There should be one ICID on this list for each Binding 
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Information in the corresponding Authorization Request. 

A value of zeroDotZero indicates the end of the list of 

ICIDs associated with an Authorization Request Decision." 
DEFVAL { zeroDotZero } 
::= { go3gppIcidEntry 3 } 



— 3GPP Go Authorization Request Directional Decision Table 

go3gppAuthReqDirDecTable OBJECT-TYPE 

SYNTAX SEQUENCE OF Go3gppAuthReqDirDecEnt ry 

PIB-ACCESS install 
STATUS current 

DESCRIPTION 

"This table represents the authorization request decision for 
unique direction (e.g. uplink and downlink) ." 
::= { go3gppDecInfoClasses 4 } 



go3gppAuthReqDirDecEntry OBJECT-TYPE 

SYNTAX Go3gppAuthReqDirDecEntry 

STATUS current 

DESCRIPTION 

"There should be one of these per direction per AuthReqDec. 
PIB-INDEX { go3gppAuthReqDirDecPrid } 
UNIQUENESS { } 
::= { go3gppAuthReqDirDecTable 1 } 



Go3gppAuthReqDirDecEntry ::= SEQUENCE { 

go3gppAuthReqDirDecPrid Instanceld, 
go3gppAuthReqDirDecDirection INTEGER, 
go3gppAuthReqDirDecQos Prid, 
go3gppAuthReqDirDecGates Prid, 
go3gppAuthReqDirDecNext Prid 



go3gppAuthReqDirDecPrid OBJECT-TYPE 

SYNTAX Instanceld 

STATUS current 

DESCRIPTION 

"An arbitrary integer index that uniquely identifies an 
instance of the go3gppAuthReqDirDec class." 

::= { go3gppAuthReqDirDecEntry 1 } 



go3gppAuthReqDirDecDirection OBJECT-TYPE 
SYNTAX INTEGER { 

uplink ( 1 ) , 
downlink (2) 
} 
STATUS current 

DESCRIPTION 

"Indicates the direction this decision applies to. 
::= ( go3gppAuthReqDirDecEntry 2 } 



go3gppAuthReqDirDecQos OBJECT-TYPE 
SYNTAX Prid 

STATUS current 

DESCRIPTION 

" The Authorized QoS. References the go3gppQos class." 
::= ( go3gppAuthReqDirDecEntry 3 } 



go3gppAuthReqDirDecGates OBJECT-TYPE 
SYNTAX Prid 

STATUS current 

DESCRIPTION 

"References the first instance of a list of the go3gppGate class. 
::= ( go3gppAuthReqDirDecEntry 4 } 



go3gppAuthReqDirDecNext OBJECT-TYPE 
SYNTAX Prid 

STATUS current 
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DESCRIPTION 

"References the next instance of a list of 

goSgppAuthReqDirDec class." 
::= { go3gppAuthReqDirDecEntry 5 } 



— 3GPP Go QoS Table 

go3gppQosTable OBJECT-TYPE 

SYNTAX SEQUENCE OF Go3gppQosEnt ry 

PIB-ACCESS install 
STATUS current 

DESCRIPTION 

"This table represents the Authorised QoS. 

It is referenced by the go3gppAuthReqDirDecQos entry of the 

go3gppAuthReqDirDecEntry class. " 
::= { go3gppDecInfoClasses 5 } 



go3gppQosEntry OBJECT-TYPE 

SYNTAX Go3gppQosEntry 

STATUS current 

DESCRIPTION 

"There should be one of these per direction per AuthReqDec' 
PIB-INDEX { go3gppQosPrid } 
UNIQUENESS { } 
::= { go3gppQosTable 1 } 



Go3gppQosEntry ::= SEQUENCE { 
go3gppQosPrid 
go3gppQosServiceClass 
go3gppQosDataRateUnit 
go3gppQosDataRate 

} 



Instanceld, 
INTEGER, 
INTEGER, 
Unsigned32 



go3gppQosPrid OBJECT-TYPE 

SYNTAX Instanceld 

STATUS current 

DESCRIPTION 

"An arbitrary integer index that uniquely identifies an 

instance of the go3gppQos class." 
::= { go3gppQosEntry 1 } 



go 3 gppQos Service 


:C1 


ass OBJECT-TYPE 




SYNTAX 




INTEGER { 








qosclassA 


(1 






qosclassB 


(2 






qosclassC 


(3 






qosclassD 


(4 






qosclassE 


(5 






qosclassF 


(6 


STATUS 




current 





DESCRIPTION 

"The QoS Service Class indicates the highest authorized QoS class. 
::= { go3gppQosEntry 2 } 



go3gppQosDataRateUnit OBJECT-TYPE 
SYNTAX INTEGER { 

bps (1), 
kbps (2), 
mbps (3) 
} 
STATUS current 

DESCRIPTION 

"Indication of the unit of measure for go3gppQosDataRate, 
in bits per second, kilo bits per second, or mega bits per 
second. " 
::= { go3gppQosEntry 3 } 
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goSgppQosDataRate OBJECT-TYPE 
SYNTAX Unsigned32 
STATUS current 

DESCRIPTION 

"The Data Rate with unit of measure indicated by 

goSgppQosDataRateUnit . " 
::= { go3gppQosEntry 4 } 



3GPP Go Gate Decision Table 



— There could be one of these per direction per GateDec. 

— This is for changing Gating Status only when used alone 

— (not as part of Direction Decision) . 

— goSgppGateDec is sent in a different COPS DEC message 

— from the DEC message carrying goSgppAuthReqDec , PDF must 

— have sent a goSgppAuthReqDec before using goSgppGateDec. 

goSgppGateDecTable OBJECT-TYPE 

SYNTAX SEQUENCE OF GoSgppGateDecEnt ry 

PIB-ACCESS install 
STATUS current 

DESCRIPTION 

"This table represents an updated gating decision." 
::= { goSgppDecInfoClasses 6 } 



goSgppGateDecEntry OBJECT-TYPE 

SYNTAX GoSgppGateDecEntry 
STATUS current 

DESCRIPTION 

"There should be one of these per direction per AuthReqDec. 
PIB-INDEX { goSgppGateDecPrid } 
UNIQUENESS { } 
::= { goSgppGateDecTable 1 } 



GoSgppGateDecEntry 



SEQUENCE { 



goSgppGateDecPrid Instanceld, 

goSgppGateDecDirection INTEGER, 

goSgppGateDecGates Prid, 

goSgppGateDecNext Prid 



goSgppGateDecPrid OBJECT-TYPE 
SYNTAX Instanceld 

STATUS current 

DESCRIPTION 

"An arbitrary integer index that uniquely identifies an 

instance of the goSgppGateDec class." 
::= { goSgppGateDecEntry 1 } 



goSgppGateDecDirection OBJECT-TYPE 
SYNTAX INTEGER { 

uplink ( 1 ) / 
downlink (2) 
} 
STATUS current 

DESCRIPTION 

"References the gate direction." 
::= { goSgppGateDecEntry 2 } 

goSgppGateDecGates OBJECT-TYPE 
SYNTAX Prid 

STATUS current 

DESCRIPTION 

"References the first instance of a list of goSgppGate class. 
::= { goSgppGateDecEntry S } 



£75/ 



3GPP TS 29.207 version 6.4.0 Release 6 43 ETSI TS 1 29 207 V6.4.0 (2005-06) 



go3gppGateDecNext OBJECT-TYPE 
SYNTAX Prid 

STATUS current 

DESCRIPTION 

"References the next instance of a list of go3gppGateDec class." 
::= { goSgppGateDecEntry 4 } 



3GPP Go Gate Table 

go3gppGateTable OBJECT-TYPE 

SYNTAX SEQUENCE OF GoSgppGateEnt ry 

PIB-ACCESS install 
STATUS current 

DESCRIPTION 

"PRC representing a Gate." 
::= { goSgppDecInfoClasses 7 } 



go3gppGateEntry OBJECT-TYPE 

SYNTAX Go3gppGateEntry 

STATUS current 

DESCRIPTION 

"Each instance represents one Gate. 
PIB-INDEX { goSgppGatePrid } 
UNIQUENESS { } 
::= { go3gppGateTable 1 } 



GoSgppGateEntry ::= SEQUENCE { 

go3gppGatePrid Instanceld, 

goSgppGateFilter Prid, 

goSgppGateStatus INTEGER, 

goSgppGateNext Prid 

} 



goSgppGatePrid OBJECT-TYPE 

SYNTAX Instanceld 

STATUS current 

DESCRIPTION 

"An arbitrary integer index that uniquely identifies an 

instance of the goSgppGate class." 
::= { goSgppGateEntry 1 } 



go3gppGateFilter OBJECT-TYPE 
SYNTAX Prid 

STATUS current 

DESCRIPTION 

"References an entry in f rwklpFilterTable (Framework PIB) 
that describes the applicable classification filter. 

When a decision requiring the definition of an IP filter 

is sent to the GGSN, the IP filter will be represented by the 

IP filter definition f rwklpFilterTable, provided by the 

Framework PIB, RFC 3318. Such IP filter f rwklpFilterTable 

must be part of the same decision message. The attribute 

go3gppGateFilter is used to reference the f rwklpFilterTable 

entry for this Gate. 

Wildcarding of the attributes for deriving the address and protocol values 

is as specified in RFC 3318 [15] . Wildcarding of the source ports is achieved as follows: 

- frwkIpFilterSrcL4PortMin shall be set to 0, 

- and f rwkIpFilterSrcL4PortMax shall be set to 65535 

The f rwkBaseFilterNegation attribute of the f rwkBaseFilterTable is 
not required, its "not-used" condition is indicated by setting its 
value to "false". 

The f rwklpFilterDscp and f rwklpFilterFlowId attributes 

of the f rwklpFilterTable are not required, their "not-used" condition is 

indicated by setting their values to -1. 
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A value of zeroDotZero indicates no filter is 
used with this goSgppGate." 
::= { goSgppGateEntry 2 } 

go3gppGateStatus OBJECT-TYPE 

SYNTAX INTEGER { 

close (1) , 
open (2) 
} 
STATUS current 

DESCRIPTION 

"Indicates if this gate will allow traffic to flow." 
DEFVAL { close } 

::= { goSgppGateEntry 3 } 

go3gppGateNext OBJECT-TYPE 
SYNTAX Prid 

STATUS current 

DESCRIPTION 

"Reference the next Gate on a list of go3gppGate instances. 
A value of zeroDotZero indicates this is the last Gate 
on the list . " 
;:= { go3gppGateEntry 4 } 



3GPP Go Reports 

PRCs for carrying the Decision enforcement result sent from PEP to PDF, 
carried using the COPS REPORT message. 

These PRCs include support for the success or failure of the PEP in 
carrying out the PDF ' s decision or -change of the state in the GGSN. 

go3gppReportTable OBJECT-TYPE 

SYNTAX SEQUENCE OF Go3gppReportEnt ry 

PIB-ACCESS notify 
STATUS current 

DESCRIPTION 

"This table represents the success or failure of the decision enforcement and 
state changes in the PEP . " 
::= { go3gppReportClasses 1 } 

go3gppReportEntry OBJECT-TYPE 

SYNTAX Go3gppReportEntry 

STATUS current 

DESCRIPTION 

PIB-INDEX { go3gppReportPrid } 

UNIQUENESS { } 

::= { go3gppReportTable 1 } 

Go3gppReportEntry ::= SEQUENCE { 

go3gppReportPrid Instanceld, 
go3gppReportStatus INTEGER, 
go3gppReportDetails Prid 



go3gppReportPrid OBJECT-TYPE 
SYNTAX Instanceld 

STATUS current 

DESCRIPTION 

"An arbitrary integer index that uniquely identifies an 

instance of the go3gpgReport class." 

::= { go3gppReportEntry 1 } 



go3gppReportStatus OBJECT-TYPE 
SYNTAX INTEGER { 



success (1) 
failure (2) 
usage (3) 



STATUS 
DESCRIPTION 
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"When Status is: 

success: Indicates the successful implementation of the 
decision. 
go3gppReportDetails : 

Reference an instance of go3gppRprtGPRSChrgInfo 
for initial authorization request decision; 
References nothing otherwise (contains the value 
zeroDotZero) . 

Failure: Indicates the failure of implementing the decision. 

goSgppReportDetails may references an Error object^ 
or may have the value zeroDotZero when no error 
object is needed, in which case COPS and COPS-PR 
error codes and error objects are sufficient. 
Usage: goSgppReportDetails references an instance of 
goSgppRprtUsage class." 

::= { go3gppReportEntry 2 } 

goSgppReportDetails OBJECT-TYPE 
SYNTAX Prid 

STATUS current 

DESCRIPTION 

"May reference an instance of goSgppRprtCPRSChrglnfo, 

goSgppRprtError (not defined), or go3gppRprtUsage class, 

or may have the value of zeroDotZero depending on the value of 

go3gppReportStatus . " 
::= { goSgppReportEntry 3 } 

go3gppRprtGPRSChrgInfoTable OBJECT-TYPE 

SYNTAX SEQUENCE OF Go3gppRprtGPRSChrgInf oEnt ry 

PIB-ACCESS notify 
STATUS current 

DESCRIPTION 

"This table represents the GPRS Charging information" 
::= { go3gppReportClasses 2 } 

go3gppRprtGPRSChrgInfoEntry OBJECT-TYPE 

SYNTAX Go3gppRprtGPRSChrgInfoEntry 

STATUS current 

DESCRIPTION 

"This entry represents the GPRS Charging Identifier and GGSN address." 
PIB-INDEX { go3gppRprtGPRSChrgInfoPrid } 
UNIQUENESS { go3gppRprtGPRSChrgInf oAddrType, 

go3gppRprtGPRSChrgInfoGGSNAddr, 

go3gppRprtGPRSChrgInfoGCID } 
::= { go3gppRprtGPRSChrgInfoTable 1 } 

Go3gppRprtGPRSChrgInfoEntry ::= SEQUENCE { 

go3gppRprtGPRSChrgInf oPrid Instanceld, 

go3gppRprtGPRSChrgInfoAddrType InetAddressType, 

go3gppRprtGPRSChrgInfoGGSNAddr InetAddress, 
go3gppRprtGPRSChrgInfoGCID OCTET STRING 



go3gppRprtGPRSChrgInfoPrid OBJECT-TYPE 

SYNTAX Instanceld 

STATUS current 

DESCRIPTION 

"An arbitrary integer index that uniquely identifies an 
instance of the go3gpgRprtGPRSChrgInfo class." 
::= { go3gppRprtGPRSChrgInfoEntry 1 } 

go3gppRprtGPRSChrgInf OAddrType OBJECT-TYPE 
SYNTAX InetAddressType 

STATUS current 

DESCRIPTION 

"The address type enumeration value to specify 
the type of the packet's IP address." 
REFERENCE 
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"Textual Conventions for Internet Network Addresses [INETADDR]." 
::= { go3gppRprtGPRSChrgInfoEntry 2 } 

go3gppRprtGPRSChrgInfoGGSNAddr OBJECT-TYPE 
SYNTAX InetAddress 

STATUS current 

DESCRIPTION 

"Contains the IP Address of the GGSN providing the GCID 

upon successful handling of an Authorization Request." 
REFERENCE 

"Textual Conventions for Internet Network Addresses [INETADDR]." 

::= { goSgppRprtCPRSChrglnfoEntry 3 } 

go3gppRprtGPRSChrgInfoGCID OBJECT-TYPE 
SYNTAX OCTET STRING 

STATUS current 

DESCRIPTION 

"The GPRS Charging ID related to this Authorization Request." 
::= { go3gppRprtGPRSChrgInfoEntry 4 } 



Notice go3gppRprtError PRC is currently not defined because all 
error condition handling is satisfactorily covered by using the 
standard COPS-PR error handling mechanism and error objects. 
go3gppRprtError PRC should only be used for 3GPP GO Application 
error indications if necessary. 



go3gppRprtUsageTable OBJECT-TYPE 

SYNTAX SEQUENCE OF Go3gppRprtUsageEnt ry 

PIB-ACCESS notify 
STATUS current 

DESCRIPTION 



{ go3gppReportClasses 3 } 



go3gppRprtUsageEntry OBJECT-TYPE 

SYNTAX Go3gppRprtUsageEntry 

STATUS current 

DESCRIPTION 

"This entry represents the PEP state changes. 
PIB-INDEX { go3gppRprtUsagePrid } 
UNIQUENESS { go3gppRprtUsageIndicat ion } 
::= { go3gppRprtUsageTable 1 } 



Go3gppRprtUsageEntry ::= SEQUENCE { 

go3gppRprtUsagePrid Instanceld, 
go3gppRprt Usage Indication INTEGER 

} 



go3gppRprtUsagePrid OBJECT-TYPE 
SYNTAX Instanceld 

STATUS current 

DESCRIPTION 

"An arbitrary integer index that uniquely identifies an 

instance of the go3gpgRprtUsage class." 

::= { go3gppRprtUsageEntry 1 } 



go 3 gppRprt Us age Indication OBJECT-TYPE 
SYNTAX INTEGER { 

chngdToOkbs (1), 
chngdFromOkbs (2) } 
STATUS current 

DESCRIPTION 

"Indication of GPRS Usage change. 
ChngdToOkbs indicates changing to Okbs, 
ChngdFromOkbs indicates changing from Okbs . " 
::= { go3gppRprtUsageEntry 2 } 
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Conformance Section 



go3gppCompliances 
goSgppGroups 



OBJECT IDENTIFIER 
OBJECT IDENTIFIER 



{ go3gppConformance 1 
( go3gppConf ormance 2 



goSgppCompliance MODULE-COMPLIANCE 
STATUS current 
DESCRIPTION 

"Describes the requirements for conformance to the 

3GPP GO PIB. " 



MODULE FRAMEWORK-PIB 

MANDATORY-GROUPS { 

frwkPrcSupport Group, 
f rwkDeviceldCroup, 
frwkBaseFi Iter Group, 
f rwklpFilterCroup } 



— Defined in RFC 3318 [15] 



MODULE G03GPP-PIB — this module 
MANDATORY-GROUPS { 

go3gppAuthReqCapGroup, 

go3gppAuthReqDecCapGroup, 

go3gppAuthReqHandlerGroup, 

go3gppAuthReqEventGroup, 

go3gppBindingInfoGroup, 

go3gppFlowIdGroup, 

go3gppAuthReqFailDecGroup, 

go3gppAuthReqDecGroup, 

go3gppIcidGroup, 

go3gppAuthReqDirDecGroup, 

go3gppQosGroup, 

go3gppGateDecGroup, 

go3gppGateGroup, 

go3gppReport Group, 

go3gppRprtGPRSChrgInfoGroup, 

go3gppRprtUsageGroup } 

::= { go3gppCompliances 1 } 



go3gppAuthReqCapGroup OBJECT-GROUP 
OBJECTS { 

go3gppAuthReqCapBindingInfos, 
go3gppAuthReqCapFlowIds 
} 

STATUS current 
DESCRIPTION 

"This Group defines the PIB Objects that describe the 
Authorization Request capabilities." 
::= { go3gppGroups 1 } 

go3gppAuthReqDecCapGroup OBJECT-GROUP 
OBJECTS { 

go3gppAuthReqDecCapIcids 
} 

STATUS current 
DESCRIPTION 

"This Group defines the PIB 

Objects that describe the Authorization Decision capabilities." 
::= { go3gppGroups 2 } 

go3gppAuthReqHandlerGroup OBJECT-GROUP 
OBJECTS { 

go3gppAuthReqHandlerEnable, 
go3gppAuthReqHandlerBindingInf o 
} 

STATUS current 
DESCRIPTION 

"This Group defines the PIB 

Objects that describe the Authorization request event handler." 
::= { go3gppGroups 3 } 
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goSgppAuthReqEvent Group OBJECT-GROUP 
OBJECTS { 

goSgppAuthReqEvent Binding Infos 
} 

STATUS current 
DESCRIPTION 

"This Group defines the PIB 

Objects that describe the Authorization request events." 
::= { goSgppGroups 4 } 

go3gppBindingInfoGroup OBJECT-GROUP 
OBJECTS { 

goSgppBindinglnfoToken, 
goSgppBindinglnfoFlowIds, 
goSgppBindingInf oNext 
} 

STATUS current 
DESCRIPTION 

"This Group defines the PIB 

Objects that describe the binding information." 
::= { goSgppGroups 5 } 

goSgppFlowIdCroup OBJECT-GROUP 
OBJECTS { 

goSgppFlowIdFlowId, 
goSgppFlowIdNext 
} 

STATUS current 
DESCRIPTION 

"This Group defines the PIB 

Objects that describe the flow identifier." 
::= { goSgppGroups 6 } 

goSgppAuthReqFailDecGroup OBJECT-GROUP 
OBJECTS { 

goSgppAuthReqFailDecReason 
} 

STATUS current 
DESCRIPTION 

"This Group defines the PIB 

Objects that describe the Authorization failure decisions." 
::= { goSgppGroups 7 } 

goSgppAuthReqDecGroup OBJECT-GROUP 
OBJECTS { 

goSgppAuthReqDecIcids, 
goSgppAuthReqDecDirDecs 
} 

STATUS current 
DESCRIPTION 

"This Group defines the PIB 

Objects that describe the Authorization decisions." 
::= { goSgppGroups 8 } 

goSgppIcidCroup OBJECT-GROUP 
OBJECTS { 
goSgppIcidValue, 
goSgppIcidNext 
} 

STATUS current 
DESCRIPTION 

"This Group defines the PIB 
Objects that describe the ICID." 
::= { goSgppGroups 9 } 

goSgppAuthReqDirDecGroup OBJECT-GROUP 
OBJECTS { 

goSgppAuthReqDirDecDirection, 
goSgppAuthReqDirDecQos, 
goSgppAuthReqDirDecGates, 
goSgppAuthReqDirDecNext 
} 

STATUS current 
DESCRIPTION 

"This Group defines the PIB 

Objects that describe the authorization decision direction." 
::= { goSgppGroups 10 } 
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go3gppQosGroup OBJECT-GROUP 
OBJECTS { 

goSgppQosServiceClass, 
go3gppQosDataRateUnit, 
go3gppQosDataRate 
} 

STATUS current 
DESCRIPTION 

"This Group defines the PIB 
Objects that describe the QoS information. 
::= { goSgppGroups 11 } 

go3gppGateDecGroup OBJECT-GROUP 
OBJECTS { 

goSgppGateDecDirection, 
go3gppGateDecGates, 
goSgppGateDecNext 
} 

STATUS current 
DESCRIPTION 

"This Group defines the PIB 
Objects that describe the Gate decision." 
::= { goSgppGroups 12 } 

goSgppGateCroup OBJECT-GROUP 
OBJECTS { 
goSgppGateFilter, 
goSgppGateStatus, 
go3gppGateNext 
} 

STATUS current 
DESCRIPTION 

"This Group defines the PIB 
Objects that describe the gate." 
::= { goSgppGroups 13 } 



goSgppReportCroup OBJECT-GROUP 
OBJECTS { 

goSgppReportStatus, 
go 3 gppReport Details 
} 

STATUS current 
DESCRIPTION 

"This Group defines the PIB 
Objects that describe the PEP reports." 
::= { goSgppGroups 14 } 

go3gppRprtGPRSChrgInfoGroup OBJECT-GROUP 
OBJECTS { 

go3gppRprtGPRSChrgInfoAddrType, 
goSgppRprtGPRSChrglnfoGGSNAddr, 
go3gppRprtGPRSChrgInfoGCID 
} 

STATUS current 
DESCRIPTION 

"This Group defines the PIB 

Objects that describe the charging information. 
::= { goSgppGroups 15 } 

goSgppRprtUsageCroup OBJECT-GROUP 
OBJECTS { 

go 3 gppRprt Us age Indication 
} 

STATUS current 
DESCRIPTION 

"This Group defines the PIB 
Objects that describe the report usage." 
::= { goSgppGroups 16 } 
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Annex C (normative): 

Flow identifiers: Format definition and examples 

C.1 Format of a flow identifier 

A flow identifier is expressed as a 2-tuple as follows: 

<The ordinal number of the position of the media component description in the SDI , The ordinal number of the IP 
flow(s) within the media component description assigned in the order of increasing downlink port numbers as 
detailed below > 

where both are numbered starting from 1. The encoding of the flow identifier is as indicated in 3GPP TS 24.008 [12]. 

If UE and AF share an algorithm for a given application, which guarantees that UE and AF assign the same ordinal 
number to each media component, the ordinal numbers of the IP Flows within a media component shall be assigned 
according to the following rules: 

• All IP flow(s) or bidirectional combinations of two IP flow(s) within the media component, for which a 
downlink destination port number is available, shall be assigned ordinal numbers in the order of downlink 
destination port numbers. 

• All IP flows, where no downlink destination port number is available, shall be assigned the next higher ordinal 
numbers in the order of uplink destination port numbers. 

The ordinal number of a media component shall not be changed when the session description information is modified. 

For SDP, the flow identifier shall be assigned in the following way: 



The ordinal number of the 
position of the "m=" line in the 
SDP 



The ordinal number of the IP 
flow(s) within the 'm=' line 
assigned in the order of 
increasing downlink destination 
port numbers, if downlink 
destination port numbers are 
available. For uplink or inactive 
unicast media IP flows, a 
downlink destination port 
number is nevertheless 
available, if SDP offer-answer 
according to RFC 3264 is used. 
The ordinal number of the IP 
flow(s) within the 'm=' line 
assigned in the order of 
increasing uplink destination 
port numbers, if no downlink 
destination port numbers are 
available. 



If no SDI with fixed and unique positions for media components is exchanged between UE and AF, the UE and AF may 
assign the ordinal numbers of the media components in another application-dependent algorithm which guarantees that 
UE and AF assign the same ordinal number to each media component. 

If UE and AF do not share an algorithm for a given application, which guarantees that UE and AF assign the same 
ordinal number to each media component, the ordinal number of the media component shall be set to zero and the 
ordinal number of the IP flows shall be assigned according to the following rules: 

1 . If ordinal numbers for several IP flows are assigned at the same time, all uplink IP flows shall be assigned lower 
ordinal number than all downlink IP flows. 
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2. If ordinal numbers for several IP flows are assigned at the same time, all uplink and all downlink IP flows shall 
separately be assigned ordinal numbers according to increasing internet protocol number assigned by lANA (e.g. 
8 for TCP and 17forUDP) 

3. If ordinal numbers for several IP flows are assigned at the same time, for each internet protocol with a port 
concept, all uplink and all downlink IP flows of this internet protocol shall separately be assigned ordinal 
numbers according to increasing port numbers. 

4. If IP flows are removed from an existing session, the previously assigned binding info shall remain unmodified 
for the remaining IP flows. 

5. If IP flows are added to an existing session, the previously assigned binding info shall remain unmodified and 
the new IP flows shall be assigned ordinal numbers following the rules 1. to 3., starting with the first previously 
unused ordinal number. The numbers freed in step 4. shall not be reused. 



C.2 Example 1 



An UE, as the offerer, sends a SDP session description, as shown in table C.2.1, to an application server (only relevant 
SDP parameters are shown): 

Table C.2.1 : The values of the SDP parameters sent by the UE in example 1. 



v=0 

o=ecsreid 3262464865 3262464868 IN IP6 2001:0646:00F1:0045:02D0:59FF:FE14:F33A 

s=MM01 

i=One unidirectional audio media and one unidirectional video media and one bidirectional application 

media 

t=3262377600 3262809600 

m=video 50230 RTP/AVP 31 

c=IN IP6 2001:0646:00F1:0045:02D0:59FF:FE14:F33A 

a=recvonly 

m=audio 50330 RTP/AVP 

c=IN IP6 2001:0646:00F1:0045:02D0:59FF:FE14:F33A 

a=sendonly 

m=application 50430 udp wb 

c=IN IP6 2001:0646:00F1:0045:02D0:59FF:FE14:F33A 

a=sendrecv 



and receives the SDP parameters, as shown in table C.2. 2, from the application server: 

Table C.2.2: The values of the SDP parameters sent by the application server in example 1. 



v=0 

o=ecsreid 3262464865 3262464868 IN IP6 2001:0646:00F1:0045:02D0:59FF:FE14:F33A 

s=MM01 

i=One unidirectional audio media and one unidirectional video media and one bidirectional application 

media 

t=3262377600 3262809600 

m=video 51372 RTP/AVP 31 

c=IN IP6 2001:0646:000A:03A7:02D0:59FF:FE40:2014 

a=sendonly 

m=audio 49170 RTP/AVP 

c=IN IP6 2001:0646:000A:03A7:02D0:59FF:FE40:2014 

a=recvonly 

m=application 32416 udp wb 

c=IN IP6 2001:0646:000A:03A7:0250:DAFF:FE0E:C6F2 

a=sendrecv 
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From this offer-answer exchange of SDP parameters the UE and the PDF each creates a Hst of flow identifiers 
comprising the IP flows as shown in table C.2.3: 

Table C.2.3: Flow identifiers in example 1. 



Order of 
"m="-line 


Type of IP flows 


Destination IP address / Port number of the IP flows 


Flow identifier 


1 


RTP (Video) DL 


2001 :0646:00F1:0045:02D0:59FF:FE14:F33A/ 50230 


<1,1> 


1 


RTCP DL 


2001 :0646:00F1:0045:02D0:59FF:FE14:F33A/ 50231 


<1,2> 


1 


RTCP UL 


2001 :0646:000A:03A7:02D0:59FF:FE40:201 4 / 51 373 


<1,2> 


2 


RTP (Audio) UL 


2001 :0646:000A:03A7:02D0:59FF:FE40:201 4 / 491 70 


<2,1> 


2 


RTCP DL 


2001 :0646:00F1:0045:02D0:59FF:FE14:F33A/ 50331 


<2,2> 


2 


RTCP UL 


2001 :0646:000A:03A7:02D0:59FF:FE40:201 4 / 491 71 


<2,2> 


3 


UDP (application) DL 


2001 :0646:00F1:0045:02D0:59FF:FE14:F33A/ 50430 


<3,1> 


3 


UDP (application) UL 


2001 :0646:000A:03A7:0250:DAFF:FE0E:C6F2 / 3241 6 


<3,1> 



C.3 Example 2 



In the general case, multiple ports may be specified with a "number of ports" qualifier as follows, RFC 2327 [17]: 

m=<media> <port>/<number of ports> <transport> <fmt list> 

An UE, as the offerer, sends a SDP session description, as shown in table C.3.1, to an application server (only relevant 
SDP parameters are shown): 

Table C.3.1 : The values of the SDP parameters sent by the UE in example 2. 



v=0 

o=ecsreid 3262464321 3262464325 IN IP6 2001:0646:00F1:0045:02D0:59FF:FE14:F33A 

s=MM02 

i=One unidirectional audio media consisting of two media IP flows described by one media 

component 

t=3262377600 3262809600 

m=audio 50330/2 RTP/AVP 

c=IN IP6 2001:0646:00F1:0045:02D0:59FF:FE14:F33A 

a=recvonly 



and receives the SDP parameters, as shown in table C.3. 2, from the application server: 

Table C.3.2: The values of the SDP parameters sent by the application server in example 2. 



v=0 

o=ecsreid 3262464321 3262464325 IN IP6 2001:0646:00F1:0045:02D0:59FF:FE14:F33A 

s=MM02 

i=One unidirectional audio media consisting of two media IP flows described by one media 

component 

t=3262377600 3262809600 

m=audio 49170/2 RTP/AVP 

c=IN IP6 2001:0646:000A:03A7:02D0:59FF:FE40:2014 

a=sendonly 



From this offer-answer exchange of SDP parameters the UE and the PDF each creates a list of flow identifiers 
comprising the IP flows as shown in table C.3. 3: 
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Table C.3.3: Flow identifiers in example 2. 



Order of 
"m="-line 


Type of IP flows 


Destination IP address / Port number of the IP flows 


Flow identifier 




RTP (audio) DL 


2001 


0646:00F1:0045:02D0:59FF:FE14:F33A/ 50330 


<1,1> 




RTCP DL 


2001 


0646:00F1:0045:02D0:59FF:FE14:F33A/ 50231 


<1,2> 




RTCP UL 


2001 


0646:000A:03A7:02D0:59FF:FE40:2014/ 49171 


<1,2> 




RTP (audio) DL 


2001 


0646:00F1:0045:02D0:59FF:FE14:F33A/ 50332 


<1,3> 




RTCP DL 


2001 


0646:00F1:0045:02D0:59FF:FE14:F33A/ 50333 


<1,4> 




RTCP UL 


2001 


0646;000A:03A7:02D0:59FF:FE40:201 4 / 491 73 


<1,4> 
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C.4 Example 3 without media components. 

The UE and AF do not exchange SDP for an appHcation and do not share an algorithm, which guarantees that UE and 
AF assign the same ordinal number to each media component. 

At the AF session initiation, the UE and AF agree to set up the following IP flows: 

Uplink UDP flow with destination port 100. 

Downlink UDP flow with destination port 100. 

Downlink TCP flow with destination port 100. 

Uplink TCP flow with destination port 100. 

Uplink UDP flow with destination port 200. 
The following binding info is assigned to these IP flows. 

- Uphnk UDP flow with destination port 100: (0, 2) 

- Downlink UDP flow with destination port 100: (0, 5) 

- Downlink TCP flow with destination port 100: (0, 4) 

- UpUnk TCP flow with destination port 100: (0, 1) 

- Uplink UDP flow with destination port 200: (0, 3) 

At a later stage in the session, the TCP IP flows are removed and the following IP flows are added: 

Uplink UDP flow with destination port 150. 

Downlink UDP flow with destination port 50. 
The following binding info is assigned to the IP flows existing at this stage: 

- Uphnk UDP flow with destination port 100: (0, 2) 
Downlink UDP flow with destination port 100: (0, 5) 

- Uplink UDP flow with destination port 200: (0, 3) 

- Uphnk UDP flow with destination port 150: (0, 6) 
Downlink UDP flow with destination port 50: (0, 7) 

C.5 Example 4 

In this example, the SDP 'a=rtcp' attribute defined in IETF RFC 3605 is used. 

An UE, as the offerer, sends a SDP session description, as shown in table C.5.1, to an application server (only relevant 
SDP parameters are shown): 

Table C.5.1 : The values of the SDP parameters sent by the UE in example 1. 



v=0 

o=ecsreid 3262464865 3262464868 IN IP6 2001:0646:00F1:0045:02D0:59FF:FE14:F33A 

s=MM01 

i=One unidirectional video media 

t=3262377600 3262809600 

m=video 50230 RTP/AVP 31 

c=IN IP6 2001:0646:00F1:0045:02D0:59FF:FE14:F33A 
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a=recvonly 
a=rtcp:53020 



and receives the SDP parameters, as shown in table C.5.2, from the application server: 

Table C.5.2: The values of the SDP parameters sent by the application server in example 1. 



v=0 

o=ecsreid 3262464865 3262464868 IN IP6 2001:0646:00F1:0045:02D0:59FF:FE14:F33A 

s=MM01 

i=One unidirectional video media 

t=3262377600 3262809600 

m=video 51372 RTP/AVP 31 

c=IN IP6 2001:0646:000A:03A7:02D0:59FF:FE40:2014 

a=sendonly 

a=rtcp:49320 



From this offer-answer exchange of SDP parameters the UE and the PDF each creates a list of flow identifiers 
comprising the IP flows as shown in table C.5.3: 

Table C.5.3: Flow identifiers in example 4. 



Order of 
"m="-line 


Type of IP flows 


Destination IP address / Port number of the IP flows 


Flow identifier 


1 


RTP (Video) DL 


2001 :0646:00F1:0045:02D0:59FF:FE14:F33A/ 50230 


<1,2> 


1 


RTCP DL 


2001 :0646:00F1:0045:02D0:59FF:FE14:F33A/ 53020 


<1,1> 


1 


RTCP UL 


2001 :0646:000A:03A7:02D0:59FF:FE40:2014/ 49320 


<1,1> 
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Annex D (normative): 

Go interface related error code values for the PDP context 

handling 

The following error codes are used to indicate Go interface related errors from the GGSN to the UE. The error codes 
listed below are transferred to the UE in the Protocol Configuration Options information element as defined in 
3GPPTS 24.008 [12]: 

The error code values transported in the container contents field shall be the binary representations of the error 
code numbers listed below. 

In all the cases listed below a common GTP cause code, "User authentication failed", see 3GPP TS 29 060 [20], 
shall be used in the response message. 

Error code No. 1 "Authorization failure of the request" 

This error code indicates that the secondary PDP context request is rejected because the authorizing entity is unable to 
provide an authorization decision for the binding information. 

Error code No. 2 "Missing binding information" 

This error code indicates that the secondary PDP context activation or PDP context modification request is rejected 
because the binding information was not included in the request although required. 

Error code No. 3 "Invalid binding information" 

This error code indicates that the secondary PDP context activation or PDP context modification request is rejected 
because the authorizing entity could not be resolved from the binding information. 

Error code No. 4 "Binding information not allowed" 

This error code indicates that the secondary PDP context activation or PDP context modification request is rejected 
because the Go interface is disabled or not supported in the GGSN and hence binding information is not allowed. The 
error code may also indicate that the PDP context modification is rejected because binding information is not allowed 
for modification of previously non-authorised PDP context or that the binding information is not allowed when the PDP 
context is indicated to be used for IMS signaling. 

Error code No.5 "Authorizing entity temporarily unavailable" 

This error code indicates that the secondary PDP context activation or PDP context modification request is rejected 
because the authorizing entity indicated by the binding information is temporarily unavailable. 

Error code No. 6 "No corresponding session" 

This error code indicates that the secondary PDP context activation request is rejected because the authorizing entity 
cannot associate the Authorisation token of binding information with any ongoing session or binding information 
contains invalid flow identifier(s).The error code also indicates that the PDP context modification request is rejected by 
the authorizing entity because the authorization token has changed or the binding information contains invalid flow 
identifier(s). 

Error code No. 7 "Invalid bundling" 

This error code indicates that the secondary PDP context activation or PDP context modification request is rejected 
because the authorizing entity does not allow the grouping of the flow identifiers in the same PDP Context. 
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Annex E (informative): 

Overview of the 3GPP Go PIB working mode 

When the GGSN initiaHse for the first time, the PEP instances are initialised. The GGSN will use a TCP connection 
with the PDF (that will be created as specified in the normative text above subclause 6.1.1) in order to transport COPS 
protocol. 

Then, the GGSN sends the first COPS REQ message to the PDF indicating capabilities and the supported PRCs. This is 
done using: 

frwkSupportXable containing the supported PRCs and attributes. 

frwkDeviceldXable used to facilitate efficient policy communication by a PDP. The PDP can take into account 
certain device characteristics during policy installation as hardware and software of the GGSN, or maximum COPS- 
PR message size. 

go3gppAuthReqCapTable indicating the maximum number of Binding Information and maximum number of 
Flow Identifiers the PEP can send with each Authorization Request. 

go3gppAuthReqDecCapTable indicating the maximum number of ICID possible in a single Authorization Request 
Decision. 

Then, the PDF send to the PEP PRCs for indicating how to handle each kind of event that require actions by the Go 
interface. This is done in a COPS DEC message using: 

go3gppAuthReqHandlerTable indicating Go actions to take at the GGSN when an Authorization Request Event is 
detected by the GGSN (an example of an Authorization Request Event is the receive of a PDP Context message); 
the maximum number of Binding Information associated with each Authorization Request; and if COPS Req. can be 
triggered, are also indicated here. 

Then, the GGSN will send PRCs to the PDF in a COPS REQ indicating the detection of specific events in the GGSN 
(i.e. when the GGSN receives the PDP context activation). Information required to PDF on behave of GGSN is carried 
also by REQ messages. This is done using: 

go3gppAuthReqEventTable indicates Authorization Request Event and its relevant information (binding 
information go3gppBindingInfoTable, go3gppFlowIDTable). 

Then, PRCs carrying the Event Decision sent from PDF to PEP are carried by the COPS DEC message. These PRCs 
include support for Gates/Filters, QoS, ICIDs. 

If the authorization request is rejected (for reasons such as no corresponding session was found by the PDF, 
incorrect bundling and others) a COPS-PR DEC containing the reason (go3gppAuthReqFailDecTable) is sent. 

If not, the following PRCs are sent: 

go3gppAuthReqDecTable indicates an ICID for each binding information received. To do so, table 
go3gppIcidTable is used. Also for each binding information a Directional Decision is sent 
(go3gppAuthreqDirDecTable) 

Within the later the following is indicated: 

- The direction where the decision applies (uplink or downlink). 

- The Auth QoS (go3gppQoSTable) indicating the service class through DSCP encoding, and the data rate 
to be applied in the PDP requesting authorization. 

The gate definition (go3gppGateTable): including status (open/closed), and Ip filter definition through 
the frwkBaseFilterXable and frwklpFilterXable (which includes source and destination address, port, 
protocol, etc). 

There is, also, the possibility of sending, in a different COPS DEC message from the one carrying the 
go3gppAuthReqDec, information about changing status of the Gate. This is done using the go3gppGateDecXable, that 
includes the direction to which this decision applies and a reference to a go3gppGateTable. 
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Finally, the PEP will send to the PDF PRCs with the information on the Decision enforcement result. This is done in the 
COPS REPORT message. These PRCs include support for the success or failure of the PEP in carrying out the PDF's 
decision or change of the state in the GGSN, and are: 

go3gppReportTable will indicate the status of the enforcement: success or failure or usage. 

- If success, then, the go3gppRprtGPRSChrgInfoTable is sent to indicate the details for charging (GGSN 
address and GCID). 

If failure, then, the standard COPS-PR error handling mechanism and error objects are enough. 

Usage means that GPRS Usage has changed to 0kbps or from 0kbps. go3gppUsageTable is used. 

To be conformant to the Go PIB, on top of the Go PIB PRCs defined in the present document, is mandatory to include 
from the framework PIB: frwkPrcSupportGroup, frwkDeviceGroup. 

The PDF can revoke the authorization by using the Remove_Decision at any time the current specification indicates that 
this action is required. The GGSN sends a COPS DRQ message to ultimately remove the corresponding state in the 
PDF. 

The Handle included in the COPS message will be used as the unique number to correlate all the COPS messages with 
the same dialogue. 
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Annex F (informative): 
Change history 
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Subject/Comment 


Old 


New 


2004-06 


NP#24 


NP-040247 


129 




Multiple IMS sessions using the same PDP context 


5.8.0 


6.0.0 


2004-09 


NP#25 


NP-040333 


132 


2 


COPS DEC message handling 


6.0.0 


6.1.0 


2004-09 


NP#25 


NP-040333 


134 


2 
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2 
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3 
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3 
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